WO2011014145A1

WO2011014145A1 - Maintaining persistent connection with user level transmission control protocol

Info

Publication number: WO2011014145A1
Application number: PCT/US2009/004403
Authority: WO
Inventors: Dekai Li; Mingquan Wu; Hang Liu; Saurabh Mathur
Original assignee: Thomson Licensing
Priority date: 2009-07-30
Filing date: 2009-07-30
Publication date: 2011-02-03
Also published as: TW201136264A

Abstract

A method is described including determining if a mobile host has moved, updating a domain name server with a current network address of the mobile host responsive to the determination, determining if a corresponding mobile host has moved and querying the domain name server responsive to the second determination. Also described is an apparatus including a key exchange module, a mobility module, a communications module and a controller module.

Description

MAINTAINING PERSISTENT CONNECTION WITH USER LEVEL TRANSMISSION CONTROL PROTOCOL

FIELD OF THE INVENTION

The present invention is directed to mobile communications and, in particular, to maintaining persistent connections when hosts move.

BACKGROUND OF THE INVENTION

In multicast and/or broadcast applications, data are transmitted from a server to multiple receivers over wired and/or wireless networks. A multicast system as used herein is a system in which a server transmits the same data to multiple receivers simultaneously, where the receivers form a subset of all the receivers up to and including all of the receivers. A broadcast system is a system in which a server transmits the same data to all of the receivers simultaneously. That is, a multicast system by definition can include a broadcast system.

There are many existing solutions to the mobility problem. Mobile Internet protocol (IP) is the standard way of achieving seamless mobility, without changing the transport layer or the application layer. However, mobile IP requires two addresses for the mobile device and a home agent, which is a computer that forwards packets between mobile host and final destination. Its triangular routing is not efficient. In triangular routing, instead of sending packets directly to the destination, a mobile host sends packets to a home agent, which in turn forwards packets to the destination. This creates a triangle. The same is true with returning packets. Moreover, deployment is a problem because a third machine is needed to forward packets and runs all the time guaranteeing security increases the complexity.

IPv6 has better support for mobility but it is not widely deployed.

Additionally, IPv6 only supports applications using exclusively IPv6. It does not support IPv6 to IPv4 mobility. That it, IPv6 is not backward compatible.

TCP-migrate is a transport layer solution to the mobility problem. However, TCP-migrate requires changing the protocol stack. It is very hard to deploy such a solution.

There are also some session layer solutions that add another layer between the application and transport layers. The session layer solutions increase the complexity of the whole system and thus require more system resources. SUMMARY OF THE INVENTION

The need for communication anytime anywhere has driven the development of various networks, e.g. Ethernet, 3G, WiFi, WiMAX, Bluetooth, GPRS, and many types of portable/mobile devices. These developments have enabled users to roam freely without losing network access.

Modern mobile (portable) devices are usually equipped with multiple interfaces for multiple networks. For example, a user might use a smart phone to access 3G while on the road but the same user may use WiFi at his or her office. When a wireless network is used, intermittent connection loss occurs frequently. For example, a user might lose signal when in a long tunnel, crossing a long bridge or entering a building and regain the connection after a short while. A new address might be assigned when the disconnection time is long enough.

The development of virtualization technologies makes it possible to migrate a running virtual machine system from one physical location to another, either live or through suspension and resumption. Even if the virtual machine has only one virtual interface, after migration it connects outside using a different physical interface. To the outside network, this VM also changes its physical address.

In all of these scenarios, mobility implies a change of network attachment point or a short period of disconnection, and thus loss of any previously established connections. Although a user can roam freely and have access to the Internet, once a connection is made, the user is wirelessly tethered to the associated network until the connection terminates (or is terminated).

Moreover, the practice of suspending a working system and resuming it later is adopted by many users and will become even more popular as virtual machine technologies become more pervasive. But the widely used connection-oriented transport protocol today does not withstand this operation. After resumption, all previously established connections are lost.

With all these technologies available, users expect a smooth, undisrupted network experience. However, the system support for such services does not exist. Current applications must come up with their own ad-hoc solutions.

A method is described including determining if a mobile host has moved, updating a domain name server with a current network address of the mobile host responsive to the determination, determining if a corresponding mobile host has moved and querying the domain name server responsive to the second determination. Also described is an apparatus including a key exchange module, a mobility module, a communications module and a controller module. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is best understood from the following detailed description when read in conjunction with the accompanying drawings. The drawings include the following figures briefly described below:

Fig. IA is a schematic diagram showing the migration path of a mobile device from a 3G network to a WiFi network with the mobile device connected initially to Host A through the 3 G network.

Fig. IB is a schematic diagram showing the migration path of a mobile device from a 3G network to a WiFi network with the mobile device connected finally to Host A through the WiFi network.

Fig. 2A is a schematic diagram showing the migration path of a virtual machine having a connection to Host A, and which is initially running in Host B and which later migrates to Host C.

Fig. 2B is a schematic diagram showing the migration path of a virtual machine having a connection to Host A, and which is finally running in Host C.

Fig. 3 shows user level TCP directly on top of the kernel network layer.

Fig. 4 shows user level TCP used on top of UDP.

Fig. 5 is a flowchart of an exemplary embodiment f the method of the present invention.

Fig. 6 illustrates an exemplary packet format when UDP is used as the underlying protocol.

Fig. 7 illustrates an exemplary pseudo header.

Fig. 8A shows the structure of the user level TCP on client side when a connection is established.

Fig. 8B shows the structure of the user level TCP on server side when a connection is established.

Fig. 9 is a block diagram of a mobile host. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Instead of changing the standard and waiting for widespread deployment, the present invention uses a user level, modified TCP to maintain persistent connections to support mobility across different networks and transparently handle system suspension and resumption. Applications can use TCP as an integrated module to handle timing, packet transmission and reception, etc. It is also possible to use a dedicated process for user level TCP, similar to the micro-kernel approach. Compared with previous approaches, the present invention has the following advantages:

• The present invention is independent of the network layer protocol, and thus the method of the present invention can seamlessly migrate between different network protocols, e.g. from IPv4 to IPv6, or be used on top of existing protocols, e.g. UDP.

• The present invention is an end-to-end solution. Thus, no network support is needed.

• Applications only need to be slightly modified. Existing protocols can be used without modification and a new protocol does not need to be deployed. Thus, deployment is easier. Moreover, a proxy application can use the method of the present invention to provide support to legacy applications such that legacy applications can remain unchanged.

• The present invention is based on the well-defined TCP standard, so that existing implementations, which are widely tested and mature can be reused. Application layer protocols, e.g. HTTP, SMTP, can directly make use of the method of the present invention to achieve the same reliability as TCP.

• Many problems are already solved by employing a standard implementation, e.g. reliable delivery, congestion control, flow control, and round trip time estimation.

• Because the method of the present invention is integrated into an application, other applications' security will not be affected. Maintaining persistent connection with user level TCP

Conventionally, a TCP connection is identified by a tuple: <source ip address, source port, destination ip address, destination port>. When an address changes, existing connections are broken.

In the present invention, the dynamic domain name is used as a level of indirection. Indirection as used herein means that a domain name is used to identify the corresponding mobile host (instead of IP address), because the domain name remains the same while the IP address can change to separate the lifetime of a connection from the duration of possession of a specific network address. Location service is provided by dynamic domain name server (DDNS). A corresponding mobile host is a mobile device that is remote form the mobile host. Both the mobile host and the corresponding mobile host have the same functionality and operating ability and both may move. At any point in time a mobile host and a corresponding mobile host may exchange positions.

As used herein mobile host includes mobile devices, mobile terminals, end devices, peers, clients, client devices, nodes, stations, mobile stations, laptops, personal digital assistants, dual mode smart phones and any other type of mobile device that uses a wireless network. Any of the above mobile devices may be virtualized.

When a mobile host changes its network address, it securely updates the dynamic name server with its new address. Then the mobile host starts using the new network address to send packets to the corresponding mobile host. The corresponding mobile host is any other mobile device with which the originating mobile host was communicating. Either the mobile host or the corresponding mobile host may be transmitting and/or receiving at any point in time. That is, each (the mobile host and the corresponding mobile host) can be a transceiver. When the corresponding mobile host receives the transmitted packets, it notices the source address change in the received packets. The corresponding mobile host then uses the new address to transmit (send, forward) reply (response) packets. Thus, from the application's perspective, the user level TCP connection remains connected even if the mobile host's network address changes. When the connection resumes (recovers from the disruption or suspension), it is possible that the network condition (state) is different. The user level TCP should restart the congestion control process, e.g. from slow start, instead of using the previous congestion control state.

If the disconnection period has been long enough, it is possible that before the mobile host acquires a new address and starts sending packets to the corresponding mobile host, the corresponding mobile host has already timed out. In this case, after a configurable number of retries, the corresponding mobile host also queries the domain name server for the current address of the mobile host. If there is an update, the new address will be used. Otherwise, it uses a timer to periodically query regarding the new address.

Another possibility is that the corresponding mobile host receives an Internet

Control Message Protocol (ICMP) destination unreachable or protocol unreachable message after the mobile host moves. In this case, the corresponding mobile host knows that the mobile host is in the process of acquiring a new address and thus, sets a timer to periodically query the domain name server the new address of the mobile host.

Yet another possibility is that the old address of the mobile host is assigned to another mobile host before the disconnected mobile host acquires a new address. In this case, the corresponding mobile host may or may not receive a notification message in response to the packets it has sent, depending on the implementation. For example, if UDP is used as the underlying protocol, an ICMP port unreachable message will be returned if there is no application listening on that port. It is also possible for the corresponding mobile host to receive a TCP reset message. In all of these cases, the corresponding mobile host can ignore these messages and periodically query the domain name server for the mobile host's new address If user level TCP is used on top of UDP, the method of the present invention only binds to a local port and does not bind the remote address and port. In socket programming, "bind to a port" means specifying to the system to receive packets destined to this port. Binding to an address means only receive packets destined to this address (if a new address is used, packets can not be received). So that after moving, the peer can still receive packets from the corresponding mobile node, which now has a new address. If both IPv4 and IPv6 are used, each communicating side (e.g., host) uses two UDP sockets to receive packets through IPv4 networks and IPv6 networks. When a burst of packets is sent by either host, it is possible that the sending host's local buffer is filled up and some packets cannot be queued. In this case, the TCP activates congestion control. For example, if UDP is used as the underlying protocol and synchronous socket send is used, the send operation returns when the packet is put into the send queue. If asynchronous socket operation (using either an asynchronous socket or the MSG DONTW AIT flag) is used and there is no buffer available, the return value is EAGAIN or EWOULDBLOCK.

In order to get a timely address update, the domain name server does not allow DNS caching (mapping of the domain name to the IP address) of the mobile host.

In Fig. IA, a dynamic name server is connected to both 3G network and WiFi network through a backbone network. The mobile host starts a connection in the 3G network to HOST A and then the mobile host moves so the connection is migrated to the WiFi network.

In Fig. IB, after acquiring a new address in the WiFi network, the mobile host updates the dynamic name server with its new address. HOST A notices the address change and starts sending packets to the mobile host using the mobile host's new address, through the same connection established in Fig. IA. It is the same connection even though the physical address is different because Host A still has an established session with the mobile host. Even though HOST A is shown as being directly connected to the backbone network, it is also possible that HOST A is connected through an access network. It is further possible that HOST A might also move, just like the mobile host.

In Fig. 2A, a virtual machine running in HOST B establishes a connection with HOST A. Then the virtual machine moves from HOST B to HOST C.

In Fig. 2B, after moving from HOST B to HOST C, the virtual machine updates the dynamic domain name server with its new network address. HOST A notices the address change and starts sending packets to the mobile host using the new address through the same connection established in Fig. 2A. It is the same connection even though the physical address is different because Host A still has an established session with the virtual machine.

In Fig. 3, user level TCP is shown directly on top of the kernel network layer. For example, the kernel can deliver raw IP packets to the user level TCP and the user level TCP sends raw IP packets. In this case, the protocol type field in the IP packet header might be a new type. If the protocol type field is still TCP, then packets for conventional TCP must be able to be clearly distinguishable from packets for user level TCP. One solution is to share the port number space with conventional TCP and divert user level TCP packets directly to the user level TCP.

Fig. 4 shows user level TCP is used on top of UDP. In this case, user level

TCP packets are sent and received through a UDP socket.

Because of the presence of UDP header in each packet, when calculating available space for a TCP packet, the UDP header length must be taken into account. For example, if the original maximum segment size is MSS, the new size is MSS - 8. The length of the UDP header is 8 bytes.

Securely migrating a connection

By breaking the binding between TCP connection endpoints and network address, connections can survive network address changes. However, it is possible for an attacker to "hijack" a connection by first sniffing the traffic of an existing connection and using a new address to take over the connection. In order to securely update the endpoints of an existing connection, the method of the present invention uses a method based on a shared secure key to protect against such attacks.

The key is exchanged at the beginning of a connection before any data is exchanged. It is assumed that during the key exchange phase, the two communicating mobile hosts do not change network addresses. Three possible ways of securely exchange key are:

1. Use beginning of TCP connection. Key exchange can follow the steps of

TLS (Transport Layer Security).

2. Use TCP option at user level using Elliptic Curve Diffie-Hellman (ECDH).

3. Use a secure connection to exchange key(s). For example, the SSL (Secure

Socket Layer) or the TLS (Transport Layer Security) can be used to securely exchange the shared key.

After two communicating mobile hosts agree on the shared key, subsequent communication can be protected. The authenticity as well as the secrecy of the communication can thus be protected.

Fig. 6 illustrates a packet format when UDP is used as the underlying protocol. At the left in the most significant position is an IP layer protocol header (IPv4 or IPv6) followed by a UDP header. The connection ID is used to identify a particular connection if multiple connections use the same UDP socket. This connection ID is similar to the concept of a session ID. There are two major differences:

1. The connection ID is below the TCP layer and maintains the same TCP connection while session ID is above the TCP layer and maintains the same session with possibly multiple TCP connections.

2. The connection ID is transmitted with each packet while the session ID is usually for local use and not transmitted.

Then a Message Authentication Code (MAC) is used to guarantee the authenticity of this packet. The user level TCP header and payload are at the end of the packet.

The connection ID is a randomly chosen number that uniquely identifies a connection, even after the network address changes. It is selected at the beginning of a connection and should not conflict with other connections used by both mobile hosts. The connection ID reuses the port numbers of UDP header or user level TCP header. In these cases, the MAC immediately follows the UDP header. If user level TCP port numbers are not used, they can also be deleted to reduce total header size.

The MAC is a hash value of the whole or part of the packet. Although SHAl is used herein as an exemplary embodiment, other hashing algorithms, e.g. MD5, SHAl, etc. are also possible.

If it is desirable to protect against routing error or header corruption only then is it possible to calculate the MAC based on information in the user level TCP header:

MAC = SHAl (key, tcpjieader, length)

To guarantee the authenticity of the whole packet, the hash can also be computed (determined, calculated) including the payload:

MAC = SHAl (key, tcpjieader, length, packet_payload)

However, the message is still transmitted using clear text. In order to ensure the secrecy of the packet content, the packet payload can be encrypted first and the encrypted content can be transmitted. encrypted_pay_load = encrypt(key, packet_payload)

MAC = SHAl (key, tcpjieader, length, encrypted_pay_load) Upon receiving the encrypted packet, the receiver (mobile host or corresponding mobile host) first verifies the integrity of the packet by calculating the hash. If the hash is correct, the receiver then decrypts the packet to get the original content (pay load).

Another unlikely but possible attack is to wait for the sequence number to wrap around and perform a replay attack. In a replay attack, attacking hosts sniff all the traffic and replay (resend) past traffic to interfere with a new communication connection. In this case, the TCP TIMESTAMP option for each packet can be used, so that the possibility of two packets sharing the same header is almost 0.

If security is not required, then the MAC can be deleted.

Fig. 5 is a flowchart of the method of the present invention to solve the mobility problem using user level TCP. Fig. 5 shows the flow chart for both sides (both hosts - the mobile host and the corresponding mobile host), because both sides may move. In processing block 505 "key exchange", communicating hosts exchange the shared key that is used later for secure mobility. This process can be performed during connection establishment, e.g. through TCP options in the TCP SYN segment. It can also be performed after the three-way handshake has completed but no data exchange has begun. In processing block 510 "send/receive data", communicating hosts exchange data. An exemplary embodiment of the packet format is illustrated in Fig. 6 described above. At 515 a test is performed to determine if the communication has finished/completed. If the communication has finished/completed, control goes to the terminating block "End" and processing is terminated. If the communication has not finished (completed), control is transferred to processing block 520 "local mobility check". The local mobility check (test, determination) can be performed by comparing the current network address (for example, IP address) of the mobile host with the previously used network address of the mobile host. It is also possible in the case of a suspended virtual machine that the same address is assigned to the resumed virtual machine so the address remains unchanged. A test (check, determination) is performed at 525 to determine if the mobile device or virtual machine has moved. If the mobile device or virtual machine has moved, the domain name server is updated with the current address at 530. At 535 "peer mobility check" processing block checks (determines) whether the corresponding side (mobile host) has a changed address or not. The corresponding mobile host might also move and thus change address. If the corresponding mobile host (remote mobile host, remote peer) moves and gets a new address, then the old address of the corresponding mobile host might not be used or the old address might be used by another mobile host. The peer mobility check can be performed via a retransmission timeout or reception of certain messages, e.g. ICMP host unreachable message, ICMP port unreachable message, etc. If the old address is not used, then the mobile host will timeout when it tries to send data to an address for a corresponding mobile host that is no longer used (no longer exists). If the old address is reused (has been reassigned to another mobile host by the DNS) then the mobile host will receive an ICMP message. A test is performed at 540 to determine if the peer's corresponding and originating address has changed. If the peer's corresponding and originating mobile host address has changed, its new address is queried for use in subsequent communication at 545. The domain name server has a fixed address and records the current IP address of the hosts. If the peer's (corresponding and originating mobile host) address has not changed, then processing proceeds to 510. If the mobile device or virtual machine has not moved, then processing proceeds to 535.

This method can be further optimized. If no message authentication code or encryption is used, the key exchange step is not necessary. When there are multiple sessions, it is only necessary to update the domain name server once when the mobile host moves. Similarly, when the corresponding host moves and there are multiple sessions with this host, it is only necessary to query the domain name server for its new address once and use the new address for all of the sessions.

Checksum calculation

In order to prevent a host from receiving unwanted packets due to routing error or data corruption, traditional TCP checksum calculation includes not only the

TCP header and payload, but also a pseudo header which includes the source IP address, the destination IP address, the packet length, and the protocol type. An exemplary pseudo header is shown in Fig. 7. If the mobile host moves and its network address changes, the packets sent to the corresponding host contain a different source address and, thus, the pseudo header must be constructed on a per-packet basis in order to pass the checksum test (check, determination). However, it is possible that when a mobile host moves and acquires a new address, packets sent to the old mobile host address (with the same address) may also pass checksum verification. It is then up to the user-level TCP to verify the validity of the received packets.

By separating the TCP connection from the network address, it is possible to not include the IP address in the checksum calculation, but rather to use the connection ID as the end-to-end identification and for the checksum calculation. If the MAC covers the whole packet, it is unnecessary to perform conventional checksum verification. Similarly, if UDP is used and the UDP checksum function is enabled, the user level TCP checksum is not necessary. Application crash detection

It is possible that an application crashes in the middle of a connection. Without notification to the contrary, the corresponding host will continue waiting, assuming that the other side (mobile host) has moved. This leads to local resource consumption on the waiting side. Without proper handling, the resource cannot be released until a system restart.

An extended DDNS server, which responds to a name query and the last update time, is used. That is, the extended DDNS server does not merely respond with the network address. The probing side non-crashed side (host) keeps a copy of the other (crashing) side's (mobile host) network address and last update timestamp. If the network address is updated and the probing side does not receive the message it expected, the other side can be assumed crashed and the mobile host can be subsequently restarted. For example, when the other mobile host restarts and updates the DDNS with its new network address, the sending side (non-crashing mobile host) can get a UDP port unreachable message or ICMP protocol unreachable message and thus release the local resources.

However, there is the possibility that either host (corresponding mobile host or mobile host) crashes and remains down for a very long time. In this case, the other communication side (non-crashing mobile host) does not know when to release the local resources. To solve this problem, a maximum persist time that times out orphaned connections is specified.

Example application: Telnet

To demonstrate how the method of the present invention can be used to support mobility, a telnet application is used as an example. UDP is used as the underlying protocol and the TCP port numbers are used as the connection ID.

1. Server initializes a user level TCP socket listening on port 23;

2. Server creates a UDP socket and receives packets on UDP port 2323;

3. Client initializes a user level TCP socket and randomly chooses a user level TCP port, for example 3000;

4. Client opens a UDP socket and binds to a local port, for example 5000;

5. Client sends user level TCP packets through UDP socket to the server at port 2323;

6. Server receives user level TCP packets and finds the listening user level TCP socket at local port 23;

7. Server creates another user level TCP sockets with <local port 23, remote port 3000> and creates another thread for this connection;

8. Server sends packets through the local UDP socket to client at port 5000.

When the client moves, it gets a new address and uses the new address to send user level TCP packets encapsulated in UDP packets to the server. The server notices the address change in the received packets and uses that address for sending reply packets to the client. The IP address is not used in identifying the TCP connection. The connection ID (in this case, the TCP port number) is used instead.

Fig. 8A shows the structure of the user level TCP on client side when a connection is established. User level TCP uses local port 3000 and remote port 23. The underlying UDP socket has local port 5000.

Fig. 8B shows the structure of the user level TCP on server side. UDP port

2323 is used for receiving user level TCP packets. User level TCP socket with local port 23 is in listen state. Another user level TCP socket with local port 23 and remote port 3000 is in established state. Fig. 9 is a block diagram of a mobile host. Since both the mobile host and corresponding mobile host have the same functionality and can effectively be either at any point in time, the block diagram is the same for both the (originating) mobile host and corresponding (remote) mobile host. The modules (components) of the mobile host may be implemented hardware, software and/or firmware or any combination of the above including applications specific integrated circuits (ASICs), reduced instruction set computer (RISC), field programmable gate arrays (FPGAs) and any other equivalent structure. The controller module controls the other modules. The key exchange module is used to exchange keys if necessary for security (secure connection). The mobility check module checks whether local address has changed (the mobile host or virtual machine has moved) and updates the domain name server if the mobile host or virtual machine has moved (changed address). This is called local mobility check herein. It also checks the mobility of the corresponding mobile host. If the remote address (of the corresponding or remote mobile host) has changed, this module will use the new address for future communication. The data exchange module is used for exchanging data between two mobile hosts (originating and corresponding (remote)). The communication module is used for transmitting and receiving data packets. Data packets include any data or messages such as ICMP messages. If the mobile host (or corresponding mobile host) is a virtual machine, all these modules are the components of the virtualized machine.

It is to be understood that the present invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Preferably, the present invention is implemented as a combination of hardware and software. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage device. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPU), a random access memory (RAM), and input/output (I/O) interface(s). The computer platform also includes an operating system and microinstruction code. The various processes and functions described herein may either be part of the microinstruction code or part of the application program (or a combination thereof), which is executed via the operating system. In addition, various other peripheral devices may be connected to the computer platform such as an additional data storage device and a printing device.

It is to be further understood that, because some of the constituent system components and method steps depicted in the accompanying figures are preferably implemented in software, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present invention is programmed. Given the teachings herein, one of ordinary skill in the related art will be able to contemplate these and similar implementations or configurations of the present invention.

Claims

CLAMS:

1. A method, said method comprising: determining if a mobile host has moved;

updating a domain name server with a current network address of said mobile host responsive to said determination;

determining if a corresponding mobile host has moved; and

querying said domain name server responsive to said second determination.

2. The method according to claim 1, wherein said first determining act further comprises determining said movement based on comparing said current network address of said mobile host with a previous network address of said mobile host.

3. The method according to claim 1, wherein said second determining act further comprises determining said movement is accomplished by one of a retransmission timing out and receiving a message.

4. The method according to claim 1, further comprising exchanging data, wherein exchanging data comprises one of transmitting data and receiving data.

5. The method according to claim 1, wherein said mobile host is a virtual machine.

6. The method according to claim 1, wherein said corresponding mobile host is a virtual machine.

7. The method according to claim 1, further comprising exchanging keys.

8. The method according to claim 1, wherein a user level transmission control protocol (TCP) performs the acts of exchanging data, exchanging keys, first and second determinations, updating and querying.

9. An apparatus, said apparatus comprising: a mobility module for determining if one of said apparatus and a - corresponding apparatus has moved; and

a module for exchanging keying information.

10. The apparatus according to claim 9, wherein said mobility module further updates said domain name server.

11. The apparatus according to claim 9, wherein said mobility module further queries said domain name server.

12. The apparatus according to claim 9, further comprising a module for handling communications between said apparatus and a wireless network and any other devices in said wireless network.

13. The apparatus according to claim 9, further comprising a module for exchanging and processing data, a module for controlling the actions of said mobility module, said key exchange module and said data exchanging and processing module.