WO2009018658A1

WO2009018658A1 - Device, system and method for automatic ipv4 provisioning in a local area network connected to an ipv6 network

Info

Publication number: WO2009018658A1
Application number: PCT/CA2008/001417
Authority: WO
Inventors: Eric Melin; Mikael Lind
Original assignee: Hexago
Priority date: 2007-08-03
Filing date: 2008-08-01
Publication date: 2009-02-12

Abstract

A protocol tunneling device for supporting communication between a local IPV4 data source comprising a network layer identified by a data source IPv4 address and located on a local area network and a remote IPv4 data sink, the data source communicating using IPv4 protocol data packets with the data sink via a communications path comprising the protocol tunneling device, an IPv6 router and a tunneling end point, the protocol tunneling device, router and tunneling end point communicating using an IPv6 protocol, the tunneling end point and the data sink communicating using the IPv4 protocol, and the protocol tunneling device and the data source communicating using the IPv4 protocol.

Description

TITLE OF THE INVENTION

DEVICE, SYSTEM AND METHOD FOR AUTOMATIC IPV4 PROVISIONING IN A LOCAL AREA NETWORK CONNECTED TO AN IPV6 NETWORK

CROSS REFERENCE TO RELATED APPLICATIONS

[001] This application claims priority on U.S. Provisional Application No. 60/953,784, filed on August 3, 2007 and which is herein incorporated by reference in its entirety.

FIELD OF THE INVENTION

[002] The present invention relates to an interoperability device, system and method for automatic IPv4 provisioning in a Local Area Network connected to an IPv6 network. In particular, the present invention relates to a device for providing transparent data communications between networked devices communicating using a first protocol, illustratively IPv4, where the networked devices are interconnected via at least one network segment using a second protocol, illustratively IPv6, which is incompatible with the first protocol. Still more specifically, the present invention relates to an interoperability device with one network interface providing outside connectivity across the IPv6 network segment and one network interface providing IPv4 routing functionalities to

IPv4 enabled networked devices in the Local Area Network.

BACKGROUND TO THE INVENTION

[003] The exponential development of IP based devices, and associated services, has created a need and an expectation, for end users, to have access to their favorite applications (mail, web, video streaming, etc.), wherever they are located, by means of IP networks. This trend has lead to the availability of IP based networking in corporate sites, over the cellular infrastructure, at home, in open WiFi hotspots, etc.

[004] IPv4 is already deployed in most existing IP based infrastructures, and provides access to both the Internet and to private IP networks (such as a corporate network). Success in the deployment of the IPv4 protocol has lead to rapid exhaustion of the pool of available IPv4 addresses.

[005] In order to address the above drawback, one prior art solution uses private IPv4 addresses (which are not unique and can be reused in different independent networks), in conjunction with Network Address Translation (NAT) technologies. This has enabled large corporate sites, Internet Service Providers (ISPs) and mobile cellular operators to support a large number of new customers without changes to the existing IPv4 protocol. However, one drawback of this solution is a more complex network infrastructure and a deployment of peer-to peer services such as VoIP, video-conferencing, on-line gaming (where each peer typically requires a known public IP address that is easily distinguished from any other peer) which is much more difficult.

[006] In order to address the above drawbacks, IPv6 was developed. In particular, the IPv6 protocol has been designed to address those problems associated with the exhaustion of the IPv4 address space. With an almost unlimited pool of IPv6 addresses (public by nature), each user (and even each device at home, in a car, etc.), can be allocated a unique IPv6 address. This significantly simplifies the deployment of services based on the peer to peer paradigm which as a result can be deployed at a lower cost than with IPv4.

[007] In a first step of the deployment of the IPv6 protocol, and at least for an interim "transition" period, a large portion of the network infrastructure will support IPv4 only, or will optionally be dual stack. Thus, one issue will be to provide IPv6 connectivity to IPv6 compatible devices, across IPv4 only network infrastructures. In a second step however, the maturity of IPv6 technologies and the advantages of the IPv6 protocol in terms of new service deployments (e.g. peer to peer) and network operations will drive the deployment of IPv6 only networks. Indeed, with the pre-eminence of IPv6, the cost of operating a dual stack network can be avoided and IPv4 addresses saved. In this context, the main issue, which will be relevant to any type of activity including corporate sites, ISP, and cellular operators, will become the provisioning of IPv4 connectivity to IPv4 compatible devices, across IPv6 only network infrastructures. The typical use case is a legacy IPv4 device (for example an application server), which, either cannot be upgraded to dual stack, or supports several IPv4 only applications. Such a device is illustratively located in an IPv6 only portion of the network infrastructure, and is unable to communicate with other IPv4 devices (for example clients) located in another portion of the network infrastructure, since the intermediate network infrastructure supports only IPv6.

[008] The above problem has been investigated in some depth, in particular by the Internet Engineering Task Force (IETF). One effective and scalable solution proposed to overcome this problem is the use of "IPv4-in-IPv6 tunneling", where IPv4 packets are transferred using IPv6 packets, and which enables an isolated IPv4 enabled client, host or network to exchange IPv4 packets with a different IPv4 enabled client, host or network separated from the isolated IPv4 enabled client, host or network by an IPv6 network.

The main solution proposed by the IETF is the Dual Stack Transition

Mechanism (DSTM) referred to in Internet-Draft "draft-bound-dstm-exp-04.txt".

DSTM is also referenced in "draftblanchet-v6ops-tunnelbroker-tsp-03", to address IPv4-in-Pv6 tunneling needs. [009] In one prior art version of IPv4-in-IPv6 tunneling, IPv4 enabled clients interact with a central server via an IPv6 only network in order to negotiate the particular properties of the tunnel and will be accorded a tunnel end-point. This tunnel end-point can be the client itself (the client must then be enabled for IPv4-in-IPv6 tunneling), or a dedicated default router implementing IPv4-in-IPv6 tunneling (this router may then serve several clients). This solution is typically deployed by installing dedicated software for tunnel negotiation and setup on each client. However, this solution is not always scalable, and it is necessary to upgrade the software on each client in order to provide them with this IPv4-in- IPv6 tunneling capability.

[010] Consequently, there exists a need for a solution to simplify the provisioning of IPv4 connectivity to one or several IPv4 enabled devices located "behind" an IPv6 only network. This solution will offer the standard functionalities of an IPv4 router to the IPv4 enabled devices, and will provide IPv4 connectivity over the IPv6 only network, by means of IPv4-in-IPv6 tunneling.

SUMMARY OF THE INVENTION

[011] The present invention addresses the above and other drawbacks by providing a protocol tunneling device for supporting communication between a local IPV4 data source comprising a network layer identified by a data source IPv4 address and located on a local network and a remote IPv4 data sink, the data source communicating using IPv4 protocol data packets with the data sink via a communications path comprising an IPv6 router and a tunneling end point. The router and tunneling end point communicate using an IPv6 protocol and the tunneling end point and the data sink communicate using the IPv4 protocol. The device comprises an IPv4 network layer compatible with the IPv4 protocol for communicating with the data source, the IPv4 network layer identified by an IPv4 compatible address, an IPv6 network layer compatible with the IPv6 protocol for communicating with the IPv6 router, the IPv6 network layer identified by an IPv6 compatible address, a tunneling client providing a tunnel to the tunneling end point via the IPv6 network layer and the IPv6 router, and a n IPv4 routing function. IPv4 data packets compatible with the IPv4 protocol and for transfer to the IPv4 data sink received from the IPv4 data source at the IPv4 network layer are encapsulated in IPv6 data packets by the tunneling client, the IPv6 data packets transmitted to the tunneling end point via the IPv6 network layer and the IPv6 router using the IPv6 protocol for subsequent transmission to the data sink as IPv4 data packets using the IPv4 protocol.

[012] There is further provided data communication system comprising a data source identified by a data source IPv4 address and located on a local network, and a data sink located on a remote IPv4 network. The data source communicates with the data sink using an IPv4 protocol via a communications path comprising an IPv6 router located on the local network and an intermediate IPv6 network and a tunneling end point located on the intermediate IPv6 network and a remote IPv4 network. The data communication system also comprises a protocol tunneling device located on the local network. The tunneling device comprises a first network layer compatible with the IPv4 protocol, the first network layer identified by a first address compatible with the IPv4 protocol, a second network layer compatible with the IPv6 protocol, the second network layer identified by a second address compatible with the IPv6 protocol, a tunneling client providing a tunnel to the tunneling end point via the IPv6 router and the intermediate IPv6 network using the IPv6 protocol and an IPv4 routing function. When IPv4 data packets for transfer to the data sink are received from the data source at the first network layer, the tunneling client encapsulates the IPv4 data packets into IPv6 data packets by the tunneling client and transmitted to the tunneling end point via the second network layer, the IPv6 router and the intermediate IPv6 network segment using the IPv6 protocol, the tunneling end point removing the IPv4 data packets from the IPv6 data packets and subsequently transmitting the IPv4 data packets to the data sink using the IPv4 protocol.

There is further provided a method for transferring IPv4 data packets between an IPv4 data source on a local network and a remote IPv4 data sink on a remote IPv4 network via an intervening IPv6 network. The method comprises providing an IPV6 router between the local network and the intervening IPv6 network and a tunneling end point between the intervening IPv6 network and the remote IPv4 network, establishing an IPv6 tunnel between a protocol tunneling device on the local network and the tunneling end point via the IPv6 router and the intervening IPv6 network, the protocol tunneling device comprising an IPv4 routing function, receiving the IPv4 data packets at the protocol tunneling device from the IPv4 data source, encapsulating the received IPv4 data packets into IPv6 data packets, transferring the IPv6 data packets from the protocol tunneling device to the tunneling end point via the IPv6 router and the intervening IPv6 network, receiving the IPv6 data packets at the tunneling end point, decapsulating the IPv4 data packets from the received IPv6 packets, and transmitting the decapsulated IPv4 data packets to the IPv4 data sink via the remote IPv4 network.

BRIEF DESCRIPTION OF THE DRAWINGS

[013] Figure 1 is a block diagram of an interoperability device in accordance with an illustrative embodiment of the present invention;

[014] Figure 2 is a block diagram of the architecture of the interoperability device and related network devices in accordance with an illustrative embodiment of the present invention; [015] Figure 3 is a block diagram of an architecture of an interoperability communication system in accordance with an illustrative embodiment of the present invention;

[016] Figure 4 is a block diagram of an interoperability device implemented on a corporate network in accordance with an illustrative embodiment of the present invention; and

[017] Figure 5 is a flow chart detailing the actions performed by the interoperability device in accordance with an illustrative embodiment of the present invention.

DETAILED DESCRIPTION OF THE ILLUSTRATIVE EMBODIMENTS

[018] Referring now to Figure 1 , an interoperability device, generally referred to using the reference numeral 10, will now be described. The interoperability device 10 is illustratively comprised of a CPU 12 under control of program code and configuration information stored in a ROM 14 and/or a RAM 16. The CPU 12 receives, handles and transmits packets (not shown), illustratively packets conforming to IPv6, via a network interface 18.1 , which provides the interoperability device 10 access to a first IPv6 network segment 20.1 and packets conforming to IPv4, via a network interface 18.2, which provides the interoperability device 10 access to a second network segment, such as a Local Area Network (LAN), or "local network" 20.2. In a particular embodiment, a serial interface 22, such as a USB interface, could be provided, for example to allow the interoperability device 10 to be configured using another suitably equipped computing device (not shown) such as a personal computer, PDA or the like. A power supply 24 is also provided in order to supply the components with the requisite current to ensure their correct operation. [019] Still referring to Figure 1 , in a particular embodiment Direct Memory Access (DMA) is provided between the network interfaces 18.1 and 18.2, and RAM 16 in order to allow for the direct transfer of incoming packets from the network interfaces 18.1 and 18.2 to the RAM 16 and direct transfer of outgoing packets from the RAM 16 to the network interfaces 18.1 and 18.2. Additionally, although the network interfaces as 18.1 and 18.2 are illustrated as comprising a direct physical connection, respectively 26.1 to the IPv6 network segment and 26.2 to the LAN 20.2, for example when the access technology conforms to Ethernet (e.g. IEEE 802.3), Firewire (IEEE 1394) or the like, other wireless technologies such as WiFi (e.g. IEEE 802.11) may also prove suitable in a given application. The RAM 16 may also be used to store routing tables and the like (not shown).

[020] Referring now to Figure 2, an illustrative embodiment of the architecture 28 of the interoperability device 10 is provided. The architecture is comprised of a four (4) layer TCP/IP protocol stack 30, a configuration interface 32 and a tunneling client (such as a TSP client with DSTM support) 34. The tunneling client 34 and the configuration interface 32 both take advantage of the communication services provided by the TCP/IP protocol stack 30 in order to communicate with other network devices (e.g. the peer tunneling server 48 for the tunneling client).

[021] Still referring to Figure 2, the TCP/IP protocol stack 30 is comprised of a transport layer 36 which can establish end-to-end communications with other suitably equipped network devices using either TCP or UDP. Additionally, a first network layer 38 compliant with a first protocol such as IPv4 is provided in order to communicate with other IPv4 compatible network devices located in the LAN 20.2, as well as with remote IPv4 hosts located in an IPv4 network segment beyond the peer tunneling server 48. A second network layer 40 compliant with a second protocol such as IPv6 is also provided in order to communicate over the IPv6 network segment, mainly with the peer tunneling server 48, via other IPv6 compatible network entities such as a router 42. Furthermore, in order to access the network segments 20.1 , 20.2 that the interoperability device 10 resides in, a data link layer 44, for example an Ethernet (as defined in IEEE 802.3) or WiFi (as defined IEEE 802.11) data link layer is provided. The data link layer 44 is interconnected with other network devices via the physical layer 46, for example a twisted pair cable, fiber optic cable, RF wireless transceiver or the like.

[022] Still referring to Figure 2, the configuration interface 32 allows parameters to be configured, for example when automatic configuration is otherwise unavailable. This would allow the configuration interface 32 to be accessed via the TCP/IP protocol stack 30, for example using a web browser if HTTP support and suitable web based configuration pages are provided by the configuration interface 32. Alternatively, the serial (USB) interface (reference 22 in Figure 1), if available, could be used to provide access to the configuration interface 32.

[023] A number of other parameters could also be preconfigured or modifiable via the configuration interface 32. For example, a fully qualified domain name of a web site where the interoperability device 10 can retrieve updates and the like. Additionally, a number of parameters related to the configuration of the tunneling client 34 (the operation of which will be explained in more detail hereinbelow). For example, the fully qualified domain name of the host 48 on which the tunneling end point 50 resides with which the tunneling client 34 wishes to establish a tunnel 52 via the external IPv6 network segment (or "domain") 20.1 could be configured via the configuration interface 32. A Domain Name Server (DNS, not shown) could then be used to look up the actual IPv6 address of the TSP peer 50. Other parameters include those credentials necessary to authenticate the tunneling client 34 with the tunneling end point 50 when establishing the tunnel 52.

[024] Referring now to Figure 3, the interoperability device 10 provides IPv4 connectivity to IPv4 enabled network devices, or "data sources", as in 54 located in the LAN 20.2, which, without the presence of the interoperability device 10, would not be capable of communicating with remote IPv4 correspondents, or "data sinks" 56, across the IPv6 network segment 20.1. These IPv4 enabled network devices do not have the capability to use the native IPv6 protocol for communication: either their IP stack is IPv4 only and cannot be upgraded to support IPv6, or they provide services / applications that only work with the IPv4 protocol and cannot be upgraded. Such IPv4 network devices will be grouped in the LAN 20.2 and all other hosts using the IPv6 protocol only, will be located in the IPv6 network segment 20.1. Thus a dual stack environment is not being primarily considered, but rather a network configuration where most hosts have been transitioned to IPv6 and are located in an IPv6 network segment 20.1 with IPv6 support only, and a few IPv4 only hosts are located in a dedicated LAN 20.2, to support legacy services that cannot be operated over the IPv6 protocol in the IPv6 network segment 20.1. However, this does not preclude that the separate LAN segment 20.2 cannot support IPv6 at the same time as supporting IPv4.

[025] Note that, in a particular embodiment, the LAN 20.2 may be reduced to a single IPv4 enabled network device 54 directly connected to the interoperability device 10, via network interface 18.2.

[026] One aspect of the interoperability device 10 is that it automatically provisions IPv4 connectivity in the LAN 20.2 where it is connected. In this regard the interoperability device 10 illustratively includes all the necessary networking protocols and functionalities to offer IPv4 connectivity to the IPv4 enabled network devices 54 within the LAN 20.2 (by means of standard IPv4 networking procedures over the LAN 20.2), as well as outside the LAN 20.2 (by means of IPv4-in-IPv6 tunneling). One feature of the interoperability device 10 is that no software upgrade or modification to the IPv4 enabled network devices is required, provided the IPv4 enabled network devices as in 54 are equipped with those minimum set of functionalities required for an IPv4 host to operate on the LAN 20.2. Additionally, no software upgrade or modification is required to the IPv6 enabled network devices located in the IPv6 network segment 20.1 , IPv6 enabled router 42 or other IPv6 enabled networking (such as other routers, gateways, firewalls, etc.) equipment found on the IPv6 network segment 20.1.

[027] Referring back to Figure 2 in addition to Figure 3, the LAN 20.2 is connected to a second network segment, for example an external IPv6 network 20.1 (which could be a corporate network or the service infrastructure network of a cellular operator or ISP, like the IMS) via the interoperability device 10. As discussed above, a variety of IPv4 enabled network devices 54 may be attached to the LAN 20.2. For example, in a corporate environment, such IPv4 enabled network devices may include legacy IPv4 only application servers, printers, etc. Similarly, in an IPv6 IMS deployment, such IPv4 enabled network devices, would support IPv4 only services, that a cellular operator or ISP cannot or does not want to transition to IPv6, typically mainly for reasons related to cost. The interoperability device 10 has two network interfaces 18.1 and 18.2, attached respectively to the IPv6 network segment 20.1 and the LAN 20.2.

[028] The interoperability device 10 illustratively provides two main groups of functions in order to support the IPv4 enabled network devices 54 resident on the LAN 20.2. [029] Firstly, the interoperability device 10 provides those functions as would normally be expected from an IPv4 Router. In this regard, in the LAN 20.2 where the IPv4 enabled network devices 54 are all part of the same IPv4 subnet, the interoperability device 10 would typically provide each IPv4 enabled network device as in 54 with an IPv4 address, as well as a netmask, a default IPv4 gateway (the interoperability device IPv4 network interface) and a DNS server with IPv4 transport. This would be performed by means of DHCPv4 operations, the interoperability device 10 having an embedded DHCPv4 server and each of the IPv4 enabled network devices 54 preferably having an embedded DHCPv4 client (otherwise, only static configuration of these IPv4 hosts can be achieved, as will be detailed later). This would then allow the IPv4 enabled network devices 54 attached to the LAN 20.2 to discover each other using the ARP protocol and transfer packets between one another directly using IPv4 without the intervention of the interoperability device 10.

[030] Secondly, provided the IPv4 enabled network devices 54 have the IPv4 address of the interoperability device 10 configured as their default IPv4 gateway, the interoperability device 10 provides those functions necessary to interconnect the data source IPv4 enabled network devices 54 resident on the LAN 20.2 with remote data sinks such as IPv4 enabled network devices as in 56 located on a remote IPv4 network segment 58, but accessible only via the intermediate IPv6 network segment 20.1 (connected to the IPv6 network interface 18.1 of the interoperability device 10). In this regard, the interoperability device 10 illustratively provides IPv4-in-IPv6 tunneling and acts as one of the tunnel end points. The other tunnel end point is, for example, an IPv6 / IPv4 router (providing a tunnel server functionality) 60 illustratively interconnecting the remote IPv4 network segment 58 with the intermediate IPv6 network segment 20.1. Of course, in order for the interoperability device 10 to communicate with the tunnel end point located at the tunnel server 60, a compatible tunneling mechanism must be implemented in both the interoperability device 10 and the tunnel server 60.

[031] As will now be apparent to a person of skill in the art, IPv4 networking is used to support communications between the IPv4 enabled network devices 54 in the LAN 20.2 and the interoperability device 10; and between the tunnel server 60 and the remote IPv4 enabled network devices 56. IPv4-in-IPv6 tunneling is performed between the interoperability device 10 and the tunnel server 60 (which provides the remote tunnel end point) via the IPv6 enabled router 42 and any other IPv6 router in the path.

[032] In an alternative illustrative embodiment of the present invention, the tunnel server 60 is replaced by a Tunnel Broker Server (TBS). Illustratively, the IPv4-in-IPv6 tunnel, as well as the interaction between the interoperability device 10 and the TBS, complies with that as described in US Patent Applications entitled "Method and apparatus for connecting IPv4 devices through an IPv6 network using a tunnel setup protocol" and published with the numbers 2004/0088385 A1 and 2006/0248202 A1 , which are incorporated herein by reference in their entirety.

[033] Referring now to Figure 4 in addition to Figure 1 , in a further illustrative embodiment of the present invention, we consider a corporate network that has been fully transitioned to IPv6 and no longer supports IPv4 networking. However, a few IPv4 network devices as in 54 still need IPv4 networking capabilities, and have been grouped in a "legacy" LAN 20.2. The interoperability device 10 is simply connected to the IPv6 network segment 20.1 via its "IPv6" network interface 18.1. The "IPv4" network interface 18.2 of the interoperability device 10 is connected to the LAN 20.2, which is granted IPv4 connectivity across the IPv6 network segment 20.1. In the more general case, several IPv4 network devices 54, for example an IPv4 application server, a legacy IPv4 only network device, an IPv4 SIP phone, etc., may be present in the LAN 20.2. All these IPv4 network devices 54, as well as the interoperability device 10, will be inter-connected by means of a standard hub / switch 62. They will constitute the LAN 20.2, the interoperability device 10 providing all standard IPv4 routing functionalities to these IPv4 network devices 54.

[034] Referring now to Figure 5, a flow chart 64 describing the interoperability device 10 mode of operation will now be described.

[035] Referring to Figure 3 in addition to Figure 5, the first step 100 comprises configuring an IPv6 address on the network interface 18.1 of the interoperability device 10 connected to the IPv6 network segment 20.1. This is typically carried out by sending an IPv6 Router Solicitation, which will be answered by an IPv6 Router Advertisement from an IPv6 router 42 located in the IPv6 network segment 20.1. Illustratively, one way to obtain the IPv6 address is to perform IPv6 stateless auto-configuration, generating an IPv6 address based on an IPv6 prefix advertised in the Router Advertisement and the MAC address of the network interface. Another alternative is to perform stateful auto-configuration, if made mandatory by a dedicated flag in the Router Advertisement. In this case, a DHCPvδ client must be present on the interoperability device 10, to interact with a DHCPvβ server located in the IPv6 network segment 20.1 , to obtain an IPv6 address. A default route to a default IPv6 router 42 (advertised in the Router Advertisement) located in the IPv6 network segment 20.1 must also be configured and associated to the network interface 18.1 connected to the IPv6 network segment 20.1. A DNS accessible via IPv6 transport may be optionally advertised in the Router Advertisement, and should be used as the current DNS. Otherwise, a default DNS accessible via IPv6 transport should be pre-configured on the interoperability device 10 and used as the current DNS.

[036] At a second step 110, the IPv6 address of the TBS 60 is retrieved. This can be performed dynamically using for example a DNS query (provided the fully qualified domain name of the TBS 60, e.g. tunnel_broker.isp_provider.com, is available for example in a configuration file stored on the interoperability device 10). The IPv6 address of the TBS 60 can also be statically retrieved, for example from a configuration file stored on the interoperability device 10.

[037] A third step 120 comprises negotiating the IPv4-in-IPv6 tunnel parameters using TSP, between the TSP client located on the interoperability device 10 and the TBS 60. The negotiation, on the TSP client side, is typically based on pre-configured values stored in a configuration file on the interoperability device 10. Pre-configured values would typically include the version of the TSP protocol supported by the TSP client, authentication mode supported by the TSP client and associated credentials, the type of tunnel requested (v4-in-v6 in this case), etc... At the end of the negotiation, the interoperability device 10 is allocated an IPv4 address and a delegated IPv4 prefix. The IPv6 address of the associated tunnel end-point (this could be for example, the IPv6 address of the TBS 60, or the IPv6 address of an alternate tunnel end-point, such as a dual stack IPv6 / IPv4 router), as well as the IPv4 address allocated to the associated tunnel end point, are also transmitted to the interoperability device 10. A DNS with IPv4 transport should also be allocated by the TBS 60, if this option is supported by the tunneling protocol. Otherwise, a default DNS with IPv4 transport must be pre-configured on the interoperability device 10.

[038] A fourth step 130 comprises configuring the local tunnel end-point on the interface 18.1 of the interoperability device 10 connected to the IPv6 network segment 20.1 , using the parameters negotiated during step 120. In particular, the allocated IPv4 address is configured as the local tunnel end-point IPv4 address. [039] A fifth step 140 involves auto-configuration of the interoperability device 10 in order to perform IPv4 router functionalities for the IPv4 enabled network devices 54 located in the LAN 20.2. An IPv4 address is configured on the interface 18.2 connected to the LAN 20.2 (it must be consistent with the delegated IPv4 prefix). A DHCP server is configured, to allocate IPv4 addresses based on the delegated IPv4 prefix, to advertise the IPv4 address of the interface connected to the LAN 20.2 as the default IPv4 gateway, to advertise the delegated IPv4 prefix and the address of the DNS server with IPv4 transport. Alternatively, IPv4 enabled network devices 54 located in the LAN 20.2 may not have a DHCP client and may need static IPv4 configuration. In this case, the delegated prefix may be split between a range of DHCP allocated IPv4 addresses and a range of IPv4 addresses to be statically configured on the IPv4 enabled network devices 54. This may be dynamically configured on the interoperability device 10, by connecting to a simple HTTP server embedded in the interoperability device 10 (this is the usual method to configure dynamic parameters of a home gateway / router). An IPv4 route to the delegated IPv4 prefix must be associated with the interface 18.2 connected to the LAN 20.2. The default IPv4 route must be associated with the IPv4-in- IPv6 tunnel end-point.

[040] Following the fifth step 140, the interoperability device 10 is ready to act as the default IPv4 router for the IPv4 enabled network devices 54 on the LAN 20.2 and performs the following functions:

• Allows at step 150 the IPv4 enabled network devices 54 to auto-configure an IPv4 address (and the associated parameters: default IPv4 gateway,

IPv4 prefix, DNS IPv4 address), using a DHCPv4 client; the interoperability device 10 performing the DHCPv4 server.

• Routes at step 152 IPv4 traffic from the IPv4 enabled network devices 54 located in the LAN 20.2 to remote IPv4 enabled network devices 56 located in a remote IPv4 network segment 58. This traffic is transmitted via the IPv4-in-IPv6 tunnel established by the interoperability device 10. • Routes at step 154 IPv4 traffic from remote IPv4 enabled network devices 56 located in a remote IPv4 network segment 58 to the IPv4 enabled network devices 54 located in the LAN 20.2. This traffic will be received via the IPv4-in-IPv6 tunnel established by the interoperability device 10.

[041] Although the present invention has been described hereinabove by way of an illustrative embodiment thereof, this embodiment can be modified at will without departing from the spirit and nature of the subject invention.

Claims

WHAT IS CLAIMED IS:

1. A protocol tunneling device for supporting communication between a local IPv4 data source comprising a network layer identified by a data source IPv4 address and located on a local network and a remote IPv4 data sink, the data source communicating using IPv4 protocol data packets with the data sink via a communications path comprising an IPv6 router and a tunneling end point, the router and tunneling end point communicating using an IPv6 protocol, the tunneling end point and the data sink communicating using the IPv4 protocol, the device comprising: an IPv4 network layer compatible with the IPv4 protocol for communicating with the data source, said IPv4 network layer identified by an IPv4 compatible address; an IPv6 network layer compatible with the IPv6 protocol for communicating with the IPv6 router, said IPv6 network layer identified by an IPv6 compatible address; a tunneling client providing a tunnel to the tunneling end point via said

IPv6 network layer and the IPv6 router; and an IPv4 routing function; wherein IPv4 data packets compatible with the IPv4 protocol and for transfer to the IPv4 data sink received from the IPv4 data source at said IPv4 network layer are encapsulated in IPv6 data packets by said tunneling client, said IPv6 data packets transmitted to the tunneling end point via the IPv6 network layer and the IPv6 router using the IPv6 protocol for subsequent transmission to the data sink as IPv4 data packets using the IPv4 protocol.

2. The device of Claim 1 , wherein Tunnel Set-Up Protocol (TSP) is used to provide said tunnel between said tunneling client and the tunneling endpoint.

3. The device of Claim 1 , wherein said routing function provides at least a portion of the data source IPv4 address to the local IPv4 data source.

4. The device of Claim 3, wherein said routing function emits router advertisements comprising a router prefix which are received by the data source, wherein the data source comprises a unique interface identifier and further wherein the data source IPv4 address comprises the unique interface identifier appended to said router prefix.

5. The device of Claim 3, wherein said routing function comprises a DHCPv4 server and the data source IPv4 address is provided by said DHCPv4 server.

6. The device of Claim 1, further comprising a data link layer, wherein the IPv6 router comprises a plurality of ports compatible with said data link layer and a switch function for selectively interconnecting each of the ports, and further wherein said data link layer is interconnected one of the ports.

7. The device of Claim 6, wherein said data link layer is compatible with a set of standards conforming to IEEE802.3.

8. The device of Claim 6, wherein said data link layer is compatible with a set of standards conforming to IEEE802.11.

9. The device of Claim 1 , further comprising a configuration interface for configuring said IPv6 compatible address.

10. The device of Claim 9, further comprising a USB interface and wherein said configuration interface can be accessed via said USB interface.

11. The device of Claim 9, wherein said configuration interface is HTTP compatible and can be accessed via said IPv6 compatible address using a conventional Web browser.

12. A data communication system comprising: a data source identified by a data source IPv4 address and located on a local network; a data sink located on a remote IPv4 network, said data source communicating with said data sink using an IPv4 protocol via a communications path comprising an IPv6 router located on said local network and an intermediate IPv6 network and a tunneling end point located on said intermediate IPv6 network and a remote IPv4 network; and a protocol tunneling device located on said local network, said tunneling device comprising a first network layer compatible with said IPv4 protocol, said first network layer identified by a first address compatible with said IPv4 protocol, a second network layer compatible with said IPv6 protocol, said second network layer identified by a second address compatible with said IPv6 protocol, a tunneling client providing a tunnel to said tunneling end point via said IPv6 router and said intermediate IPv6 network using said IPv6 protocol and an IPv4 routing function; wherein when IPv4 data packets for transfer to said data sink are received from said data source at said first network layer, said tunneling client encapsulates said IPv4 data packets into IPv6 data packets by said tunneling client and transmitted to said tunneling end point via said second network layer, said IPv6 router and said intermediate IPv6 network segment using said IPv6 protocol, said tunneling end point removing said IPv4 data packets from said IPv6 data packets and subsequently transmitting said IPv4 data packets to said data sink using said IPv4 protocol.

13. The system of Claim 12, wherein Tunnel Set-Up Protocol (TSP) is used to provide said tunnel between said tunneling client and said tunneling endpoint.

14. The system of Claim 12, wherein said routing function comprises a DHCPv4server and said data source IPv4 address is provided by said DHCPv4 server.

15. The system of Claim 12, wherein said protocol tunneling device further comprises a data link layer, wherein said IPv6 router comprises a plurality of ports compatible with said data link layer and a switch function for selectively interconnecting each of said ports, and further wherein said data link layer is interconnected with one of said ports.

16. The system of Claim 15, wherein said data link layer is compatible with a set of standards conforming to IEEE802.3.

17. The system of Claim 15, wherein said data link layer is compatible with a set of standards conforming to IEEE802.11.

18. A method for transferring IPv4 data packets between an IPv4 data source on a local network and an IPv4 data sink on a remote IPv4 network via an intervening IPv6 network, the method comprising: providing an IPV6 router between the local network and the intervening IPv6 network and a tunneling end point between the intervening IPv6 network and the remote IPv4 network; establishing an IPv6 tunnel between a protocol tunneling device on the local network and said tunneling end point via said IPv6 router and the intervening IPv6 network, said protocol tunneling device comprising an IPv4 routing function; receiving the IPv4 data packets at said protocol tunneling device from the IPv4 data source; encapsulating the received IPv4 data packets into IPv6 data packets; transferring said IPv6 data packets from said protocol tunneling device to said tunneling end point via said IPv6 router and the intervening IPv6 network; receiving said IPv6 data packets at said tunneling end point; decapsulating said IPv4 data packets from said received IPv6 packets; and transmitting said decapsulated IPv4 data packets to the IPv4 data sink via said remote IPv4 network.

19. The method of Claim 18, wherein said IPv4 routing function comprises a DHCPv4 server and the data source IPv4 address is provided by said DHCPv4 server.