Patent Document

CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]     This is the first application filed for the present invention.  
       MICROFICHE APPENDIX  
       [0002]     Not Applicable.  
       TECHNICAL FIELD  
       [0003]     The invention relates in general to the transition of Internet Protocol (IP) networks from IP version 4 (IPv4) to IP version 6 (IPv6) and, in particular, to a method and apparatus for connecting IPv4 devices through an IPv6 network using a tunnel setup protocol.  
       BACKGROUND OF THE INVENTION  
       [0004]     Internet Protocol (IP) was created in the 1960&#39;s by the United States Advanced Research Projects Agency (ARPA). The Agency&#39;s mission was to create instruments useful for military purposes, in particular communications and decentralized computer networks. The original idea was to create connections between military bases using a decentralized communications network with a mesh structure that would permit network function despite significant damage to the country&#39;s infrastructure sustained in a military attack. In the early years of its development, the Internet was used for data transfers, principally as file transfer protocol (FTP) sessions.  
         [0005]     Use of the Internet spread from the military to the scientific and educational communities in the 1970&#39;s and 80&#39;s. Propagation of the Internet was, however, slow until the Worldwide Web (WWW) was created. The Worldwide Web was first intended to provide a convenient channel for the transfer of scientific information. However, it caught the attention of the commercial world and in the 1990&#39;s an explosive growth of the Internet ensued. That explosive growth continues today. The current Internet uses an Internet Protocol referred to as IP version 4 (IPv4). IPv4 uses address fields that are 32 bits long. Although the potential number of IP addresses is 2 32 , over 70% of those addresses have already been assigned and, if as expected the explosive growth of the Internet continues at its current pace, total exhaustion of IPv4 addresses will occur by 2006. Consequently, the Internet Engineering Task Force (IETF) has developed a new Internet standard referred to as IPv6 which uses 128-bit addressing. The address space in IPv6 is intended to accommodate connection of substantially any intelligent electronic device to the IP network. This includes mobile devices.  
         [0006]     It is well known that IPv4 and IPv6 are not compatible because of the differences in address space. Consequently, IPv4 and IPv6 networks can only be interconnected by gateway nodes provisioned with both IPv4 and IPv6 network stacks. However, because of the current lack of available IPv4 address space, IPv6 networks are being deployed and connected to the IPv4 network. A need has therefore arisen for equipment and methods to permit IPv4 devices to communicate across the IPv6 network. It is also well known that a data encapsulation technique known as tunneling can be used for transferring IPv4 packets across the IPv6 network. When an Ipv4-in-IPv6 tunnel is created, IPv4 packets are encapsulated with IPv6 headers that are used to transfer the packets through the IPv6 network to a predetermined IPv4-IPv6 host or gateway. The establishment of Ipv4-in-IPv6 tunnels is a complex process. Traditionally, the tunnels have been constructed using a manual process for setting up tunnel endpoints at edges of the IPv6 network. This is a time-consuming task that requires a considerable level of expertise and experience. Consequently, manual establishment of tunnels is unworkable with mobile devices and beyond the expertise of a majority of users.  
         [0007]     A semi-automatic establishment of IPv6-in-IPv4 tunnels is described in RFC3053 entitled “IPv6 Tunnel Broker” (January 2001). The tunnel broker described in this document is a worldwide web implementation that permits end-users to select a pre-configured IPV6-in-IPv4 tunnel. However, the system does not support any real negotiation between the end-user and the tunnel broker. If end-users use dynamic IPv4 addresses, a manual operation must be done to update the tunnel broker. This limits the scalability of deploying IPv6 networks, and introduces a considerable onus on inexperienced users.  
         [0008]     The problem of automating and simplifying the establishment of IPv6-in-IPv4 tunnels to facilitate adoption and use of IPv6, as well as to ameliorate the transition from IPv4 to IPv6 has been solved by the applicant, as described in applicant&#39;s co-pending U.S. patent application Ser. No. 10/195,396 filed Jul. 16, 2002 and entitled Method and Apparatus for Connecting IPv6 Devices Through an IPv4 Network Using a Tunnel Setup Protocol, the specification of which is incorporated herein by reference.  
         [0009]     However, as IPv6 becomes increasingly deployed, the problem shifts to being one of having to interconnect isolated IPv4 networks and/or IPv4 devices in a predominantly IPv6 network. Also, certain networks will be deployed with an IPv6 backbone first, and have to transport and support IPv4 until the entire network is eventually converted to IPv6.  
         [0010]     During the initial deployment of IPv6, hosts in native IPv6 networks have required connectivity to hosts and/or applications that can only be reached using IPv4. The Dual Stack Transition Mechanism (DSTM) provides a method to ensure this connectivity using IPv6-over-IPv4 tunnels and the temporal allocation of a global IPv6 address to hosts requiring such communication.  
         [0011]     DSTM is designed to help the interoperation of newly deployed IPv6 networks with existing IPv4 networks. Since the available IPv4 globally routable address space is becoming a scarce resource, it is assumed that users will deploy IPv6 to reduce their reliability on IPv4 within a portion of their networks. Under this premise, supporting native IPv4 and native IPv6 simultaneously significantly increases the complexity of network administration (address plan, routing infrastructure). On the other hand, if the network is configured for IPv6 alone, no IPv4 connectivity is maintained in the network.  
         [0012]     When DSTM is deployed in a network, an IPv4 address is allocated to a dual stack node if the connection can not be established using IPv6. This permits IPv6 nodes to communicate with IPv4-only nodes, or IPv4-only applications to run on an IPv6 node without modification. This allocation mechanism is coupled with an ability to perform IPv4-over-IPv6 (4over6) tunnelling, hiding IPv4 packets inside native IPv6 packets. This simplifies network management, because only the IPv6 routing plan has to be managed inside the network.  
         [0013]     The DSTM architecture requires an address server (DSTM server), a gateway and a number of nodes (DSTM nodes). The address server is in charge of IPv4 address allocation to client nodes. This allocation is very simple because there is no localization purpose in the address. The DSTM server only has to guarantee the uniqueness of the IPv4 address for a period of time. The gateway, or Tunnel End Point (TEP), can be thought of as a border router between the IPv6-only domain and an IPv4 internet or intranet. The gateway performs encapsulation/decapsulation of packets to ensure bi-directional forwarding between the two networks. Finally, in order to ensure IPv4 connectivity, nodes in the IPv6-only domain must be able to dynamically configure their IPv4 stack (by asking the address server for a temporary address) and must be capable of establishing IPv4-over-IPv6 tunnels to the TEP.  
         [0014]     DSTM may be deployed in several phases. As a first step, IPv4 connectivity may be ensured by manually configuring tunnels from a DSTM node to a TEP. However, manual configuration of tunnels is time-consuming and inefficient.  
         [0015]     Consequently, there exists a need for a method and apparatus for automating and simplifying the establishment of IPv4-in-IPv6 tunnels to facilitate communication between legacy IPv4 networks and devices, as well as to ameliorate the transition from IPv4 to IPv6 by providing a mechanism that permits a piecemeal transition to IPv6.  
       SUMMARY OF THE INVENTION  
       [0016]     It is therefore an object of the invention to provide a tunnel setup protocol for automating the establishment of IPv4-in-IPv6 tunnels through the IPv6 network.  
         [0017]     The invention provides a tunnel setup protocol that permits IPv4 devices to communicate across an IPv6 network. In accordance with the invention, a control channel is established between a tunnel client and a tunnel broker server. The control channel established between the tunnel client and the tunnel broker server is used to exchange tunnel configuration information and, optionally, to negotiate configuration parameters for the IPv4-in-IPv6 tunnel. After the tunnel configuration parameters have been established, the tunnel broker server configures a tunnel broker server endpoint. The tunnel broker server endpoint may be supported by the tunnel broker server, or by another gateway node, such as an IPv6/IPv4 router connected to both the IPv6 and the IPv4 networks.  
         [0018]     The tunnel client also configures a tunnel endpoint, referred to as the tunnel client endpoint for the IPv4-in-IPv6 tunnel. The tunnel client endpoint may likewise be configured on the tunnel client, or another IPv6/IPv4 node, such as a gateway router. In order to extend capacity, either the tunnel client or the tunnel broker server may have a list of nodes that support tunnel endpoints so that traffic loads can be distributed to improve throughput. The invention therefore permits the automated establishment of IPv4-in-IPv6 tunnels using a control channel. The use of the control channel enables the automated negotiation of specific configuration details, such as an IPv4 address range (hereinafter referred to as “IPv4 prefix” to be consistent with IPv6 terminology), DNS delegation and router peering protocol. This facilitates the preservation of legacy IPv4 networks, and ameliorates the transition from IPv4 to IPv6 by permitting a gradual transition to IPv6. The invention is particularly useful for legacy IPv4 mobile devices, since IPv4-in-IPv6 tunnels can be rapidly and automatically configured to permit true, unencumbered mobility of those devices as IPv6 becomes increasingly prevalent. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0019]     Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:  
         [0020]      FIG. 1  is a schematic diagram of a point-to-point (PPP) data connection over a dial-up link between a computer and a network access server;  
         [0021]      FIG. 2  is a schematic diagram of a connection between an IPv6/IPv4 node and an IPv4 network implemented in accordance with the invention;  
         [0022]      FIGS. 3   a - 3   d  are a flow chart of a method for connecting IPv4 devices through an IPv6 network using a tunnel setup protocol;  
         [0023]      FIG. 4  is a connection progress diagram of the establishment of an IPv4-in-IPv6 tunnel between a tunnel client and a tunnel broker server, and subsequent use of the tunnel by IPv4 nodes connected to respective IPv4 networks;  
         [0024]      FIG. 5  is a connection progress diagram of another implementation of the invention in which a tunnel client connects to a tunnel broker server and establishes an IPv4-in-IPv6 tunnel for the purposes of communicating with an IPv4 node in an IPv4 network;  
         [0025]      FIG. 6  is a connection progress diagram illustrating the establishment of an IPv4-in-IPv6 tunnel, in which the tunnel broker server configures a remote router as the tunnel endpoint for the IPv4-in-IPv6 tunnel;  
         [0026]      FIG. 7  is a connection progress diagram illustrating a method in accordance with the invention in which a tunnel client configures a remote router as the tunnel endpoint for an IPv4-in-IPv6 tunnel used to permit communication between IPv4 nodes in respective IPv4 networks;  
         [0027]      FIG. 8  is a connection progress diagram showing an implementation of the invention in which both the tunnel client and the tunnel broker server configure remote routers to serve as tunnel endpoints for an IPv4-in-IPv6 tunnel; and  
         [0028]      FIG. 9  is a connection progress diagram illustrating the establishment of IPv4-in-IPv6 tunnels by a mobile tunnel client.  
     
    
       [0029]     It will be noted that throughout the appended drawings, like features are identified by like reference numerals.  
       DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0030]     The invention provides a method and apparatus for connecting IPv4 devices through an IPv6 network using a tunnel setup protocol (TSP).  
         [0031]     In accordance with the invention, a control channel is established between a tunnel client and a tunnel broker server. Both the tunnel client and the tunnel broker server must be connected to the IPv6 network. The control channel established between the tunnel client and the tunnel broker server is used to negotiate configuration parameters for an IPv4-in-IPv6 tunnel. After the configuration parameters are established, the tunnel broker server configures a tunnel broker server endpoint and the tunnel client configures a tunnel client endpoint for the IPv4-in-IPv6 tunnel. The respective tunnel endpoints may be configured on the respective tunnel client and tunnel broker server. Alternatively, either of the tunnel client and the tunnel broker server may configure remote tunnel endpoints. In order to extend capacity, either the tunnel client or the tunnel broker server may have a list of nodes that support tunnel endpoints, so that traffic loads can be distributed to improve throughput. The invention therefore permits the automated establishment of IPv4-in-IPv6 tunnels, which facilitates the support of IPv4 nodes and networks in IPv6 networks and ameliorates the transition from IPv4 to IPv6.  
         [0032]      FIG. 1  is a schematic diagram of a point-to-point (PPP) dial-up connection between a client computer  20  and a network access server  22  to provide access to an IPv4 network  24  in a manner well known in the art. As is well understood, a PPP-control channel  26  is established over the dial-up connection between the client computer  20  and the network access server  22 . The dial-up connection passes through a modem  30 , a switched telephone network  32  and a modem bank  34  in a manner well known in the art. The PPP control channel  26  shares the dial-up connection with a PPP data channel  28 , which is used to send IPv4 data packets from the client computer  20  to one or more selected hosts in the IPv4 network  24 .  
         [0033]      FIG. 2  is a schematic diagram illustrating one implementation of a system provisioned with a tunnel setup protocol in accordance with the invention. In accordance with the invention, a control channel  40  is established through the IPv6 network  29  between a tunnel client  50  and a tunnel broker server  60  using a transmission control protocol (TCP) messaging.  
         [0034]     The control channel  40  is used to negotiate parameters for establishing an IPv4-in-IPv6 tunnel through the IPv6 network  29 . The tunnel is used to establish a data channel  42 , which extends between first and second tunnel endpoints. In this example, the tunnel endpoints are the tunnel client  50  and the tunnel broker server  60 . The data channel is used to transfer IPv4 data packets through the IPv6 network. The IPv4 data packets are encapsulated at the respective endpoints of the IPv4-in-IPv6 tunnel, as will be explained below in more detail.  
         [0035]      FIGS. 3   a - 3   d  are a flow diagram illustrating the tunnel setup protocol in accordance with the invention. The process begins in step  100  when a tunnel setup protocol (TP) client, hereinafter referred to as a tunnel client  50  ( FIG. 2 ) connects to a tunnel broker server (TB)  60  using TCP, as explained above. Alternatively, the tunnel client  50  may use User Datagram Protocol (UDP) messaging to establish the control channel  40 . After the control channel  40  is established, the tunnel client sends the version of the TSP that it supports using the control channel  40  to the tunnel broker server  60  (step  102 ). On receipt of the TSP protocol version, the tunnel broker server  60  determines whether it supports the same version of the tunnel setup protocol (step  104 ). If it is not provisioned to support the tunnel client&#39;s version of the tunnel setup protocol, the tunnel broker server  60  returns an error message via the control channel  40  (step  106 ) and branches to connector C (see  FIG. 3   d ) where the tunnel broker server  60  determines whether it has an alternate list of tunnel broker servers that it can provide to the tunnel client (as will be explained below in more detail). If the tunnel broker server  60  does support the tunnel client&#39;s version of the tunnel setup protocol, the tunnel broker server  60  returns a list of its capabilities (step  108 ) to the tunnel client  50  over the control channel  40 . The capabilities of the tunnel broker server  60  include, for example, authentication mechanisms, types of tunnel supported, lengths of IPv4 prefixes that can be assigned, as well as Domain Name Service (DNS) delegation supported, and router peering protocols supported, etc.  
         [0036]     In step  110 , the tunnel client  50  determines whether the capabilities of the tunnel broker server  60  are satisfactory for the purposes it requires. If not, the tunnel client  50  closes the tunnel setup protocol session (step  112 ) and the process ends. Otherwise, the tunnel client  50  selects an authentication mechanism from the list supported by the tunnel broker server  60  and specifies the authentication mechanism in an authentication message sent via the control channel  40  to the tunnel broker server  60  (step  114 ). Subsequently, the tunnel broker server  60  and the tunnel client  50  exchange authentication data (step  116 ) via the control channel  40 . In step  118 , the tunnel broker server  60  verifies the tunnel client authentication data.  
         [0037]     As shown in  FIG. 3   b,  after verifying the tunnel client authentication data, the tunnel broker server  60  determines whether the tunnel client  50  is authorized to establish the tunnel (step  120 ). If the tunnel client  50  is not authorized to establish the tunnel, the tunnel broker server  60  returns an error message via the control channel  40  and closes the session (step  122 ). If the tunnel client  50  is authorized to establish the tunnel, the tunnel broker server  60  returns an authentication successful message (step  124 ) to the tunnel client  50 . The tunnel client  50  then sends a tunnel request message via the control channel  40  (step  126 ) to the tunnel broker server  60 . The tunnel request message may include requests for an IPv4 prefix, a DNS delegation, router peering, etc., as will be explained below in more detail. On receipt of the tunnel request message, the tunnel broker server  60  determines whether it is provisioned to offer the service as requested (step  128 ). If not, the tunnel broker server  60  determines (step  130 ) whether it is provisioned to offer a similar service. If not, the tunnel broker server  60  returns an error message via the control channel  40  and branches to step C, where it determines in step  178  (see  FIG. 3   d ) if it is provisioned with a list of alternate tunnel broker servers. If not, it closes the session (step  180 ). If so, it returns the list via the control channel  40  to the tunnel client  50  to permit the tunnel client  50  to attempt the establishment of an IPv4-in-IPv6 tunnel using another tunnel broker.  
         [0038]     If the tunnel broker is provisioned to provide the requested service or a similar service as determined in steps  128 ,  130 , the tunnel broker server  60  assigns an IPv4-in-IPv6 tunnel to the tunnel client. The tunnel broker may also assign an IPv4 prefix in a manner well known in the art, provide domain name service (DNS) delegation, as will be explained below in more detail, and router peering to the tunnel client  50 , as appropriate (step  134 ).  
         [0039]     In step  136 , the tunnel broker server  60  determines whether DNS delegation has been requested. If so, the tunnel broker server  60  configures its DNS servers for the DNS delegation by writing the tunnel client&#39;s DNS server addresses to DNS servers associated with the tunnel broker server  60 , to point to the tunnel client&#39;s DNS servers for name space associated with the assigned IPv4 prefix (step  138 ). Then the tunnel broker server  60  configures its DNS servers with an “AAAA record” (step  140 ) for the client tunnel endpoint address, in a manner known in the art. In step  142  ( FIG. 3   c ), the tunnel broker server  60  selects and configures a tunnel endpoint for the tunnel it assigned in step  134 . The configuration of the tunnel endpoint may require configuring router peering. The tunnel broker then awaits confirmation that the tunnel endpoint configuration was successful (step  144 ). If the configuration was not successful, the tunnel broker server  60  determines in step  146  whether another tunnel endpoint is available by, for example, consulting a table of tunnel endpoints stored in the tunnel broker server memory (step  146 ). If another tunnel endpoint is not available, or all tunnel endpoints are at capacity, the tunnel broker server  60  sends an error message over the control channel (step  148 ) to the tunnel client  50  and branches to steps  178 - 180 , as explained above.  
         [0040]     If the tunnel endpoint configuration is determined to be successful in step  144 , the tunnel broker server  60  sends the tunnel configuration parameters along with any required IPv4 prefix, DNS information, router peering information, etc. to the tunnel client  50  using the control channel  40 , along with a success code (step  150 ). On receipt of this information, the tunnel client determines whether it will accept the tunnel configuration (step  152 ). If it does not find the tunnel configuration acceptable, the tunnel client determines (step  154 ) whether it will negotiate a different configuration. It should be noted that the tunnel client may be implemented with or without the capacity for parameter negotiation. If it is not equipped for negotiation or decides to terminate negotiation, the process moves to step  156 , in which the client refuses the tunnel configuration and advises the tunnel broker  60  by sending a refusal message over the control channel  40  (step  156 ). On receipt of the refusal message, the tunnel broker server  60  rolls back the configuration of the tunnel endpoint, the DNS configurations, etc. (step  158 ) and branches to steps  178 - 180 , as explained above.  
         [0041]     If the client determines in step  154  that it will negotiate the tunnel configuration, it may, for example, assess whether negotiation should proceed by comparing a negotiation count with a predetermined threshold (step  160 ). If the negotiation count is greater than the threshold, the process branches to steps  156 ,  158  and  178 - 180 , as explained above. Otherwise, the negotiation counter is incremented (step  162 ) and the tunnel client  50  returns via the control channel  40  a revised parameter list to the tunnel broker server  60  and the process branches back to step  128 .  
         [0042]     If the tunnel client accepts the tunnel configuration in step  152 , the tunnel client  50  configures its tunnel endpoint and, if required, configures its DNS server(s) as explained above, and router peering in its tunnel endpoint, if required (step  166 ). The tunnel is thus established and IPv4 traffic can be sent over the established tunnel (step  168 ). The tunnel client  50  then determines whether it wants to keep the tunnel setup protocol session alive (step  170 ). If so, the tunnel client  50  sends a keep-alive message to the tunnel broker server  60  via the control channel  40  (step  172 ) and after a predetermined time delay (step  174 ) repeats steps  170 ,  172 . If the tunnel client  50  does not wish to keep the tunnel setup protocol session alive, the tunnel client  50  closes the tunnel setup protocol session by dropping the control channel  40  (step  176 ). The tunnel established between the tunnel endpoints continues, however, for a period determined by the tunnel broker server  60 , or through negotiation with the tunnel client  50 , for a predetermined period of time, as will be explained below with reference to  FIGS. 4 and 5 .  
         [0043]      FIG. 4  is a connection progression diagram illustrating an exemplary implementation of the tunnel setup protocol in accordance with the invention. In this example, an IPv4-in-IPv6 tunnel is established between a tunnel client  50  and a tunnel broker server  60 , which respectively serve as endpoints for the tunnel. The tunnel client  50  is a router that is connected to an IPv4 network  70   a  and the IPv6 network  29 . Consequently, the tunnel client  50  is provisioned with an IPv6 stack as well as an IPv4 stack and is further provisioned to encapsulate IPv4 packets in IPv6 packets, as well as to decapsulate IPv4 packets encapsulated in IPv6 packets, to permit IPv4 traffic to pass through the tunnel. The tunnel broker server  60  is likewise connected to both the IPv6 network  29  and the IPv4 network  70  and provisioned with the same stacks and data encapsulation/decapsulation capability.  
         [0044]     As shown in the diagram, in step  200 , the router is configured as a tunnel client  50 . Once configured as a tunnel client  50  so that it knows how to contact the tunnel broker server  60 , the router is provisioned to establish a control channel  40  to the tunnel broker server  60 , as explained above. Subsequently, in step  202 , the tunnel client  50  sends a connect message to the tunnel broker server  60  to establish the control channel  40 . The tunnel client  50  may be prompted to establish the control channel for any number of reasons. For example, the tunnel client  50  is prompted to establish the control channel when the IPv4 node  72  generates IPv4 traffic addressed to an IPv4 node in a different IPv4 network, on reboot, on re-establishing IPv6 re-connectivity, etc. On receipt of the connect message, the tunnel broker server  60  returns an acknowledgement message (step  204 ) and the control channel  40  is established. The tunnel client  50  then sends the version of the tunnel setup protocol it supports to the tunnel broker server  60  (step  206 ) via the control channel  40 . The tunnel broker server  60  returns, via the control channel  40 , a list of the tunnel setup functions it supports (step  208 ). The tunnel client  50  selects an authentication mechanism and authentication information is exchanged (step  210 ). In step  212 , the tunnel broker server  60  determines that the tunnel client  50  is authorized for the service and returns an authorization successful message (step  214 ). On receipt of the message, the tunnel client  50  formulates a tunnel request message which it sends to the tunnel broker server  60  in step  216 . The request, as explained above, optionally includes a request for an IPv4 prefix, DNS delegation, and a router peering. On receipt of the request, the tunnel broker  60 , in this example, is provisioned to satisfy the request and configures a tunnel endpoint (step  218 ) to serve the request.  
         [0045]     The tunnel broker server  60  then returns a tunnel answer message (step  220 ) which includes tunnel configuration parameters, including IPv6 and IPv4 addresses for both the tunnel broker server and the tunnel client endpoints as well as any other information requested by the tunnel client  50  in step  216 . On receipt of the tunnel answer message, the tunnel client configures its tunnel endpoint (step  222 ). Thereafter, the tunnel client  50  may optionally send keep-alive messages (step  224 ), as explained above, to keep the control channel  40  open. The tunnel client may also optionally terminate the tunnel protocol session (step  226 ) at any time. After step  222  is complete, the tunnel is established and data packets can flow between the IPv4 node  72  and the IPv4 node  74 , as shown in steps  228 - 240 .  
         [0046]     Included in the information sent by the tunnel broker server  60  in the tunnel answer (step  220 ), was a tunnel lifetime parameter, which specifies a duration of the IPv4-in-IPv6 tunnel. When the tunnel lifetime expires (step  242 ), the tunnel broker server  60  deconstructs the tunnel endpoint, DNS delegation and router peering so that traffic can no longer pass through the tunnel, as explained below with reference to  FIG. 5 .  
         [0047]      FIG. 5  is a connection progression diagram that further explains the process in accordance with the invention. In this example, the tunnel setup protocol client  50  is an IPv4/6 node that serves as a tunnel endpoint. In step  250 , the tunnel protocol session parts I and II are performed as described above with reference to  FIG. 4 . In step  252 , the tunnel client  50  starts an IP session by constructing an IPv4 packet and encapsulating the IPv4 packet in an IPv6 packet in a manner known in the art. The IPv6 packet is sent in step  254  through the tunnel to the tunnel broker server  60 . The tunnel broker server  60  decapsulates the IPv6 packet (step  256 ) and forwards it in IPv4 native format to the IPv4 node  74  (step  258 ). The IPv4 node  74  returns an IPv4 packet in IPv4 native format (step  260 ). The packet is encapsulated in an IPv6 packet by the tunnel broker server  60  (step  262 ) and forwarded through the tunnel in step  264 . In step  268 , the tunnel lifetime expires and the tunnel endpoint is deconstructed, as explained above. Thereafter, when the IPv4 node  74  sends an IPv4 packet in native format (step  270 ), the tunnel broker returns a destination unreachable packet (step  272 ) in a manner known in the art.  
         [0048]      FIG. 6  is a connection progression diagram that illustrates the re-establishment of a tunnel using a tunnel setup protocol session prior to the expiry of a tunnel being used by the tunnel client. In this example, the tunnel broker server  60  configures a remote tunnel endpoint which is a router  76  connected between the IPv6 network  29  and the IPv4 network  70   b.  Network  25  is the control path between tunnel broker server  60  and router  76 . This network  25  may be IPv6, IPv4, a serial cable, SNMP or any other communications protocol that can be used to remotely configure the router  76  from the tunnel broker server  60 . In step  280 , the tunnel setup protocol session (part I) is conducted between the tunnel client  50  and the tunnel broker server  60 , as explained above with reference to  FIG. 4 . After the tunnel broker server  60  receives the tunnel request message from the tunnel client  50 , the tunnel broker server  60  configures a remote router  76  as the tunnel endpoint (step  282 ) and, the tunnel session concludes with the part II procedures described above (step  284 ). Thereafter, IPv4 node  72  connected to IPv4 network  70   a  sends IPv4 packets through the tunnel (steps  286 - 290 ) to IPv4 node  74 . Meanwhile, the tunnel client  50  monitors the lifetime of the tunnel established with the tunnel broker server  60  and, when the IPv4-in-IPv6 tunnel is about to expire, as shown at step  292 , the tunnel client  50  re-initiates tunnel setup protocol sessions parts I and II to re-establish the tunnel through the IPv6 network (step  294 ). It should be noted that the tunnel broker server  60  may route to a different tunnel endpoint to preserve service balancing. A tunnel broker server  60  configured as a host can serve multiple tunnel endpoints to enable and facilitate service balancing, etc. In that case, the tunnel endpoints are normally configured as routers  76  connected to both the IPv6 network  29  and the IPv4 network  70 . As also explained above, such routers are provisioned with both IPv6 and IPv4 stacks as well as encapsulation/decapsulation capability.  
         [0049]      FIG. 7  illustrates yet another potential configuration of a system in accordance with the invention in which the tunnel client  50  is configured as a host adapted to configure one or more remote tunnel endpoints in the same way that the tunnel broker server  60  configures remote tunnel endpoints as explained above. In step  300 , the tunnel setup protocol sessions parts I and II are performed to the point that the tunnel client configures the tunnel endpoint (step  300 ). In step  302 , the tunnel client  50  configures the remote tunnel endpoint at a router  78  selected, for example, from a table of available tunnel endpoint routers that serve as gateways to the IPv4 network  70   a.  The tunnel client  50  configures the tunnel endpoint using the IPv6 and IPv4 addresses of the tunnel endpoint  78  and the tunnel endpoint configured at the tunnel broker server  60 , received from the tunnel broker server  60  during the TSP session ( 300 ). Thereafter, the IPv4 node  72  is enabled to communicate with IPv4 node  74  using IPv4 native packets which are encapsulated, as explained above, and moved through the IPv6 network  29  (steps  304 - 308 ) using the tunnel established in steps  300 ,  302 .  
         [0050]      FIG. 8  is a connection progression diagram illustrating yet another implementation of the system in accordance with the invention in which both the tunnel client  50  and the tunnel broker server  60  configure remote tunnel endpoints. In this embodiment, the tunnel client  50  initiates and conducts a tunnel setup protocol session (step  310 ). As part of the tunnel setup protocol session, a tunnel broker server  60  configures a remote gateway router  80  to serve as a tunnel endpoint (step  312 ), as described above. The tunnel client  50  likewise configures a remote gateway router  78  to serve as a tunnel endpoint (step  314 ). Thereafter, the IPv4 node  72  is enabled to send IPv4 packets in native format to the IPv4 node  74  (steps  316 - 320 ), and vice versa.  
         [0051]      FIG. 9  is a connection progression diagram that illustrates yet another implementation of the system in accordance with the invention. In this example, the tunnel client  50  is a mobile device, such as a cellular telephone, a personal data assistant (PDA) or a laptop computer, which serves as a router for an IPv4 subnetwork. As illustrated, the mobile device in a first location functions as a tunnel client  50   a  having an IPv6 address (Add  1 ). In the first location, the mobile tunnel client  50   a  commences and performs a tunnel setup protocol session with the tunnel broker (step  330 ) and in the course of the tunnel setup protocol session receives an IPv4 prefix from the tunnel broker server  60 . In this example, the prefix received is “1.1.1.0/28”. As is well known in the art, this prefix is known as a “/28” prefix which permits the tunnel client router to assign session addresses to IPv4 devices in the domain it controls, in a manner well known in the art, for example as being a Dynamic Host Configuration Protocol (DHCP) server. After the tunnel is established in step  330 , the IPv4 node  72  is enabled to communicate with the IPv4 node  74  (steps  332 - 336 ) by sending and receiving IPv4 packets in native format. Subsequently, the mobile tunnel client  50  moves to location  50 b and its service provider in the IPv6 network assigns a new IPv6 address (Add  2 ). Consequently, a new tunnel must be established. The tunnel client  50   b  therefore initiates and performs the tunnel setup protocol session (step  338 ) with the tunnel broker server  60  and receives the same IPv4 prefix “1.1.1.0/28”. Consequently, a new tunnel is established between the mobile tunnel client  50   b  and the tunnel broker server  60  that permits the IPv4 node  72  to again send IPv4 packets in native format to the IPv4 node  74  (steps  340 - 344 ). By receiving the same IPv4 prefix, the IPv4 node keeps its same IPv4 address. Consequently, in the IPv4 realm the mobility of the IPv4 tunnel end point is not perceived and all IPv4 connections are preserved.  
         [0052]     The methods and apparatus in accordance with the invention therefore permit mobile devices to automatically establish IPv4-in-IPv6 tunnels through the IPv6 network to permit IPv4 nodes to communicate with other IPv4 nodes in other IPv4 subnetworks. This is of critical importance to the exponentially expanding use of wireless devices and mobile devices in general, and permits seamless networking of such devices. It is also of critical importance in new networks where IPv4 compatibility and access are not generalized because there is a small number of IPv4 devices. Such networks include control networks, gaming networks, etc.  
         [0053]     The embodiment(s) of the invention described above is(are) intended to be exemplary only. The scope of the invention is therefore intended to be limited solely by the scope of the appended claims.

Technology Category: 5