The present invention relates to the operation of a middlebox in an Internet Protocol (IP) network. In particular, the invention relates to a middlebox providing an interface between IP networks where an entity within one network is responsible for allocating IP addresses to entities within the other network.
A middlebox is a device which passes IP traffic from one entity and passes it to another. A general representation of the function of a middlebox is provided in
Middleboxes generally operate in one of three different modes. The first mode is known as a “bridge” mode. In this mode the middlebox has no IP address or IP addresses of its own, and simply passes IP traffic from one interface to another on a link-layer.
The second mode is a “NAT” (Network Address Translation) mode, as described in [RFC2663]. In this mode the middlebox translates between the private addresses of internal nodes to the public addresses of external nodes, and vice versa. In NAT mode the middlebox has at least two IP addresses: a public IP on an external interface, and a private IP on an internal interface.
The third mode is a “router” mode. In this mode the middlebox typically has at least two public IP addresses, and routes traffic on the network layer.
Middleboxes can be used, for example, to provide an interconnection between a home or office network and an Internet Service Provider (ISP). Typically, such a middlebox translates between the protocols used in the home and those used over the connection to the ISP. A suitable arrangement is illustrated in
It is desirable to be able to connect multiple computers to the ISP. One way of achieving this is to operate the middlebox in “NAT” mode. This enables translation between one or more public addresses allocated to the home user, and multiple local IP addresses. When operated in “NAT” mode the middlebox is also capable of providing IP address dependent services S#1, S#2, S#3, S#N, such as a Dynamic Host Configuration Protocol (DHCP) server [RFC2131], firewall and a Domain Name Service (DNS) server. However, this approach suffers from the problem that every computer in the home network, and indeed every Internet application (e.g. browser, Skype, etc.) requires its own NAT traversal code.
One solution to this problem is to provide each computer within the home network with its own IP address. The middlebox is then not required to translate between different addresses and may operate in “bridge” mode. The problem with this approach is that the computers in the network are vulnerable to an outside attack, and each must be provided with its own firewall. It is not possible to implement a firewall within the middlebox, since the middlebox, when acting as a bridge, does not have access to IP addresses, which are needed by a firewall to filter traffic. In addition, traffic between nodes within the home network are sent through the middlebox to the ISP before being routed back to home. This is extremely inefficient.
In accordance with one aspect of the present invention there is provided a method of operating a middlebox providing an interface between first and second IP networks where an entity within said first network is responsible for allocating IP addresses to an entity or entities within said second network, the method comprising:
Thus the middlebox operates in “router” mode. A router has access to the IP addresses, enabling the operation of IP address dependent services such as a firewall, DHCP server or DNS server. In some embodiments the middlebox may be an ADSL modem, Home IMS Gateway or Access Point for a WLAN.
Preferably the entity within the first network responsible for allocating IP addresses is an IP source of an ISP. The middlebox may obtain at least two IP addresses from the IP source, and assign them to external and internal interfaces of the middlebox. This step is preferably performed using an automated IP address distribution mechanism such as DHCP. The middlebox is preferably also responsible for obtaining IP addresses, on behalf of the entity or entities within the second network, from the IP source. These IP addresses are preferably obtained when said entity or entities boots up.
In one embodiment the link layer address of an external interface of the middlebox is modified in response to the addresses allocated to the entities in the second network. Public IP addresses of the entity or entities within the second network may be mapped to link layer addresses of the entities within the second network.
A further entity within the first network may also perform routing of IP traffic within and between said networks based on IP addresses, and may dynamically inform the or each IP address dependent service of addresses allocated to said entity or entities and of changes to these addresses. This further entity may obtain IP addresses on behalf of the middlebox.
The invention also provides a middlebox adapted to carry out the methods described above.
As previously discussed,
1. The AIPADIM component typically fetches two IP addresses from the IP source 24 of the ISP, and assigns them to the external 33 and internal 34 interfaces of the middlebox 31. This process is performed using an automated IP distribution mechanism such as DHCP.
2. The AIPADIM fetches IP addresses from the ISP on behalf of the internal nodes 22. This may be achieved, for example, by the middlebox fetching an IP address or addresses from the IP-source 24 whenever an internal node 22 boots up.
In some environments, especially on multi-access links, “link-layer adaptation” 35 may be needed. Link-layer adaptation is a part of AIPADIM, and can act, for example, to do the following:
The middlebox 31 also provides IP address dependent services which may include, for example, a DHCP server 311, firewall 312, and DNS server 313. The AIPADIM function 32 keeps the IP address dependent services 311-314 informed of any changes in the IP address distribution.
Even though the routing itself is not seen as a service, a reactive “routing manipulation” service 36 is also provided. The routing manipulation functionality modifies the routing table of the middlebox so that the middlebox can make a decision on what interface an incoming packet should be forwarded to. The reactive nature of routing manipulation is particularly important in an environment where the ISP distributes dynamic IP addresses.
In another example, the AIPADIM functionality may be used in a Home IP Multimedia Subsystem (IMS) Gateway (HIGA). IP Multimedia (IPMM) is a service that provides a dynamic combination of voice, video, messaging, data, etc., within the same session. The application of AIPADIM to HIGA is illustrated in
In this example, a middlebox 51, which is a HIGA, obtains IP addresses from an ISP (not shown) via an ADSL connection 53. The middlebox 51 distributes acquired IP addresses to internal nodes 52, which can be for example Session Initiation Protocol (SIP) [RFC3261] phones. The middlebox may also operate internal IP address dependent services, such as for example a SIP proxy. The AIPADIM functionality is used to keep such services informed of the IP address distribution.
In a further example the Access Point (AP) of a Wireless Local Area Network (WLAN), together with an ADSL modem, is provided with AIPADIM functionality. This example is illustrated in
In this example, the link between the ADSL modem and the middlebox uses Ethernet, which is a multi-access network. It is therefore likely that link-layer adaptation (as described with reference to
It will be appreciated that the AIPADIM functionality is useful for situations not covered by the three examples described above.
The middlebox 21 acts as a router that also provides IP address aware services. In this context, an IP address aware service signifies any service that could benefit from the knowledge of the IP address distribution. The routing itself is not seen as a service in this context.
The AIPADIM concept is especially useful in situations where public IP addresses are dynamic, i.e. situations where the IP source distributes different IP addresses over time.
It will be appreciated that a “nested” case, where the IP-source is also an entity implementing AIPADIM, is within the realm of this invention. Furthermore, the invention can be used with both IPv4 (IP version 4) [RFC791] and IPv6 (IP version 6) [RFC2460]. A middlebox implementing AIPADIM has one or more public IP addresses on its own interface or interfaces.
AIPADIM, as described herein, enables the use of middleboxes in a router mode. It also makes it possible to include IP address dependent services in the middlebox itself. Integrated reactive routing manipulation and link-layer adaptation functionalities are enablers for AIPADIM itself.
AIPADIM almost completely nullifies the need to run middleboxes either in bridged or in NAT mode. By doing so, it also provides an alternative solution which does not have the same problems that are associated with bridged and NAT mode. Furthermore, the AIPADIM concept is especially well suited to environments where public IP addresses are dynamic.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2006/069579 | 12/12/2006 | WO | 00 | 10/19/2009 |