Field of the Invention

This invention relates to a method and system for enabling network address translation (NAT) traversal for multi-homing protocols, and in particular, endpoint centric NAT traversal.

Background of the Invention

Network address translation (NAT) is a process of modifying Internet Protocol (IP) address information stored in a header of a data packet as it traverses a routing device, and will be described in more detail with reference to Fig. 1.

Fig. 1 depicts a private communications network 100 connected to a public communications network 102. First, second and third client endpoints, 104, 106, and 108, are provided within the private network 100, and are arranged to access the public network 102, such as the Internet, via a NAT router 110. The NAT router 110 is arranged to provide a mapping between private IP addresses 112, 114, and 116, of the first second and third endpoints, 104, 106, and 108, respectively, and the NAT router's public and routable IP address 118.

When the NAT router 110 receives a data packet for a given transport session from the first client endpoint 104 in the private network 100 for transmission to an endpoint 120, such as an Internet server, the NAT router 110 will modify the header information by replacing a source IP address, i.e. 112, with the NAT router's public IP address, 118, and preferably also by replacing a source port number for traffic of the transport session in the upstream, i.e. an internal port number, with a port number specific to the particular client, i.e. an external port. Thus, when the data packet is routed to the endpoint 120, the endpoint identifies the NAT router's public IP address as a source address and the external port number as a source port number and thereafter transmits data packets intended for the client to the NAT router's public IP address, i.e. 118 and the external port number. The NAT router maintains a translation table 122 to keep track of the mapping of private IP addresses to the NAT router's public IP address, and the mapping of internal port numbers to external port numbers, and thus, on receipt of data packets of the transport session intended for the client, the NAT router determines the client's private IP address and port information for the transport session from the translation table, modifies the header information to replace the NAT router's public IP address, 118, with the client's private IP address, 112, as the destination IP address, replaces the external port number with the internal port number for the identified transport session and routes the data packet to the client.

Thus, NAT routers enable multiple client endpoints in a private network 100 to access the Internet using a single public IP address, and have therefore become indispensable for home and office Internet connections.

However, problems arise where the private network supports a multi-homing protocol where multiple IP addresses, some or all of which may be private, are associated with a single client endpoint. Multi -homing is a technique often employed in order to eliminate network connectivity as a potential single point of failure (SPOF), and thereby increase the reliability and robustness of a connection. This is preferably achieved by ensuring that data travels on physically different paths when different IP addresses are utilised. Referring now to Fig. 2, there is illustrated a first endpoint 200 in a private network 201 and associated with first, second and third private IP addresses, 202a, 202b, and 202c, respectively. The first endpoint 200 is arranged to communicate with a second endpoint 204 in a public network 205 via NAT routers, 206a, 206b, and 206c, each having IP addresses 208a, 208b and 208c, respectively. In one example, a Stream Control

Transmission Protocol (SCTP) multi-homing protocol is employed in order to support the multiple IP addresses associated with the first endpoint 200.

In order to establish an association of the first endpoint 200 with the multiple IP addresses, 202a, 202b, and 202c, the first endpoint 200 is arranged to transmit, from a first interface having IP address 202a, to the second endpoint 204, an EMIT message comprising a list of the other addresses by which the client is reachable, namely, 202b, and 202c. As the message passes through the NAT router 206a, the NAT router 206a modifies the EMIT message's header information to convert the client's private IP address, 202a, to the NAT router's IP address, 208a. On reception of the EMIT message, the endpoint 204 retrieves the IP address 208a from the header, and stores it as the primary address for the client endpoint 200.

The endpoint 204 is then arranged to send an acknowledgement message to the first endpoint 200. The acknowledgment message is transmitted to the IP address 208a of the NAT router 206a, and the NAT router 206a changes a destination address in the header of the acknowledgement message from the IP address 208a of the NAT router 206a to the private IP address 202a of the endpoint client 200, as determined from a translation table (not shown).

On receipt of the EMIT message, the second endpoint 204 also retrieves from the EMIT message, the list of addresses by which the first endpoint is reachable, 202b, and 202c, and stores these addresses as secondary addresses. However, given that these are private IP addresses, they are not reachable outside of the private network 201, which includes the first endpoint 200. Thus, any traffic directed to the first endpoint 200 from the second endpoint 204 using the private IP addresses 202b and 202c will cause an error, as the private IP addresses are not recognised outside of the private network 201, and in general, the SCTP protocol will mark the private IP addresses as unreachable.

Therefore, if the first endpoint 200 tries to utilise these private non-externally routable IP addresses, 202b, and 202c, to perform a handover/failover between two interfaces of the first endpoint 200, or perform any association configurations, (ASCONF), the attempt will fail and cause an error in the SCTP association. The failure to intercept and modify the messages will result in the second endpoint 204 attempting to communicate with the first endpoint 200 using a private IP address, 202b or 202c, which causes a communication failure, and interruption of traffic.

One manner of overcoming this problem is to modify the NAT routers to enable them to understand and modify the internal signalling used by the multi-homing protocol, or by adding extra internal signalling. However, further problems arise where a security protocol has been employed to mask an internal payload. US2006/0018301 discloses a method for establishing a multi-homed connection with a number of paths between two components of a communications network. In order to address NAT traversal issues, the method modifies and extends the existing SCTP standard, therefore requiring modifications to currently deployed code bases and stacks.

US 7,685,290 is also concerned with the reliable handling of SCTP multi-homed connections across multiple NAT devices and addresses the NAT traversal problem by updating the NAT devices to understand the internal signalling mechanisms of SCTP and to dynamically modify signalling messages with translated addresses.

It is therefore an objective of the invention to provide an improved method and system for enabling NAT traversal for multi-homing protocols.

Summary of the Invention

The present invention provides a method for enabling network address translation, NAT, traversal for multi- homed protocols within a communications network, the method comprising the steps of:

a) receiving an establishment request to establish a multi-homing association from a first interface

associated with a client;

b) retrieving from the establishment request, an address for the first interface;

c) recording the address of the first interface as a primary address for the client;

d) receiving an association request to associate a secondary address with the client;

e) retrieving from the association request, an original address for the second interface;

f) utilising the original address for the second interface to determine a modified address for the second interface; and

g) creating a modified association request by replacing the original address for the second interface with the modified address.

Preferably, the step of receiving the association request comprises capturing the association request before it arrives at a multi-homing protocol stack.

Preferably, the method further comprises the step of:

h) releasing the modified association request and passing the modified association request to the multi- homing stack for processing.

Preferably, the method further comprises the step of

i) recording the modified address of the second interface as a secondary address for the client.

Preferably, said address for the first interface is a modified address for the first interface.

Preferably, the step of retrieving the address for the first interface involves retrieving the address from a header of the establishment request. Preferably, the step of retrieving the original address for the secondary interface, involves retrieving the original address from a body of the association request.

Preferably, the step of utilising the original address for the second interface to determine a modified address for the second interface comprises consulting a mapping table associated with the client.

Preferably, the method further comprises the step of

j) responsive to receipt of signalling message to establish a signalling session from the first interface associated with the client, retrieving from the signalling message, the modified address and an original address for the first interface, and creating a mapping table for the client, wherein said mapping table includes an entry providing a mapping of the original address to the modified address for the first interface.

Preferably, the method further comprises the step of:

k) responsive to receipt of a signalling message to establish a signalling session from the second interface associated with the client, retrieving from the signalling message the modified address and the original address for the second interface, and adding to the mapping table for the client, an entry providing a mapping of the original address to the modified address for the second interface.

Preferably, the method comprises carrying out steps j) and k) prior to receiving the request to establish a multi- homing association.

Preferably, the method further comprises the step of:

1) responsive to receipt of the establishment request, transmitting to the modified address for the client, an acknowledgement of receipt.

Preferably, the method further comprises the step of:

m) responsive to receipt of a signalling message to establish a signalling session from a third or an

additional interface associated with the client, retrieving from the signalling message a modified address and an original address for the third or additional interface, adding to the mapping table for the client, an entry providing a mapping of the original address to the modified address for the third or additional interface.

Preferably, said addresses are Internet Protocol, IP, addresses.

Preferably, said signalling session is established using Transmission Control Protocol, TCP, or User Datagram Protocol, UDP.

Preferably, the multi-homing association is established using a multi-homing protocol such as Stream Control Transmission Protocol, SCTP, or Multi-Path Transmission Control Protocol, MPTCP. Preferably, the method further comprises the step of:

n) responsive to receipt of a signalling message from a first interface associated with the client at the first endpoint, assigning a port number to the client endpoint, and transmitting the port number to the first interface of the client endpoint.

Preferably, the method further comprises the step of:

o) responsive to receipt of a signalling message from a second or subsequent interface associated with the client at the first endpoint, determining the port number associated with the client endpoint, and transmitting the port number to the second or subsequent interface of the client endpoint.

Preferably, the step of transmitting comprising transmitting an acknowledgement message to the first interface, the port number being included within the body of the acknowledgement message.

Preferably, the port number is a uniquely identifiable with the client.

Preferably, the establishment request includes the addresses of only the first interface associated with the client. In the preferred embodiment, the SCTP stack at the first endpoint is configured so that no other interfaces associated with the client are included within the body of the establishment request. In this way, the association created by the agent at the second endpoint will not include any non-routable addresses as secondary IP addresses associated with the client.

Alternatively, the step of receiving the establishment request comprises:

p) capturing the establishment request before it arrives at a multi-homing protocol stack;

q) deleting addresses associated with interfaces other than the first interface from the establishment request; and

r) releasing and passing the establishment request to the multi-homing protocol stack for processing.

In this case, the agent at the second endpoint is arranged to delete the non-routable addresses associated with interfaces other than the primary interface associated with the client at the first endpoint. Furthermore, the agent may be arranged to delete any information associated with interfaces other than the first or primary interface from the establishment message.

Alternatively, step of receiving the establishment request comprises:

s) retrieving from the establishment request, an original address for a secondary interface associated with the client;

t) utilising the original address for the secondary interface to determine a modified address for the

secondary interface; and

u) creating a modified establishment request by replacing the original address for the secondary interface with the modified address. In this case, the agent at the second endpoint is arranged to modify the secondary IP addresses within the establishment request with their routable addresses as determined from the mapping table, before allowing the establishment request proceed to the multi-homing stack for processing.

In a further aspect of the present invention, there is provided a method for enabling network address translation, NAT, traversal for multi-homed protocols within a communications network, the method comprising the steps of:

a) receiving an establishment request to establish a multi-homing association from a first interface

associated with a client;

b) retrieving from the establishment request, an original address for a second interface associated with the client;

c) utilising the original address for the second interface to determine a modified address for the second interface; and

d) creating a modified establishment request by replacing the original address for the second interface with the modified address.

Preferably, the step of retrieving the establishment request comprises capturing the establishment request before it arrives at a multi-homing protocol stack.

Preferably, the method further comprises the step of:

e) releasing the modified establishment request and passing the modified establishment request to the multi-homing stack for processing.

Preferably, the method further comprises the steps of:

f) retrieving from the establishment request, an address for the first interface;

g) recording the address of the first interface as a primary address for the client; and

h) recording the modified address of the second interface as a secondary address for the client.

There is further provided a system for enabling network address translation, NAT traversal for multi-homed protocols within a communications network, the system comprising an agent deployed at an endpoint, the agent arranged to carry out the steps of any of the methods described above.

There is further provided a computer program product comprising a non-transitory computer readable medium encoded with computer executed instructions, which when executed in a computing device, is arranged to carry out the steps of any of the methods described above.

The present invention provides an endpoint centric solution to the problem of NAT traversal for multi -homed protocols, such as SCTP or Multi-path TCP. Advantageously, the present invention does not involve modifications to the underlying protocol stack, or modifications to the NAT methods employed in the NAT routers. Furthermore, no modifications or agents are required at the client endpoint, which is of distinct advantage in cases where the invention is being implemented with devices with limited resources such as mobile devices and/or in which the alternative endpoint is operating as a proxy, endpoint, or data gateway. In this way, multi-homed protocols can operate over networks using existing NAT routers or gateways and can utilise their in-band signalling mechanisms even when security mechanisms, such as Internet Protocol Security (IPSec), are being used.

Brief Description of the Drawings

Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Fig. 1 illustrates a communications network including a plurality of client endpoints provided within a private network, and arranged to communicate with a public network;

Fig. 2 illustrates a communications network including a first endpoint provided within a private network and associated with a plurality of IP addresses, and arranged to communicate with a public network;

Fig. 3 a and Fig. 3b is a message flow depicting steps of a method for enabling NAT traversal for multi -homed protocols within the communications network of Fig. 2, according to the preferred embodiment of the invention;

Fig. 4 is a mapping table including entries mapping original IP addresses to modified IP addresses associated with the first endpoint of Fig. 2; and

Fig. 5 is a message flow depicting steps of a port negotiation mechanism employed in the method of Fig. 3, in an embodiment of the present invention.

Detailed Description of the Invention

Referring to Fig. 3, there is illustrated a message flow depicting steps of establishing an association between multiple IP addresses of the first endpoint 200 of Fig. 2, according to a preferred embodiment of the invention.

The first endpoint 200, or client, transmits a first signalling message to a second endpoint to establish an out-of band signalling session with the second endpoint 204, step 300. The out-of-band signalling sessions are preferably separate sessions to the subsequent sessions of data flow discussed below in relation to association establishment and configuration messages and may be carried out using a single homing protocol such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) or a multi-homing protocol such as SCTP.

The first signalling message includes a unique identifier of the first endpoint 200 and an original IP address 202a indicating an original source IP address of a first interface of the first endpoint 200. Preferably, the unique identifier of the first endpoint 200 and the original source IP address 202a are provided within the body of the signalling message. As the signalling message traverses the NAT router 206a, the NAT router 206a modifies a source IP address in the header by replacing the source IP address 202a of the first endpoint 200, with an IP address 208a of the NAT router 206a, step 302, and relays the message to the second endpoint 204, step 304.

On receiving the signalling message at the second endpoint 204, an agent (not shown) deployed at the second endpoint 204 creates a mapping between the source IP address in the header of the message, namely, the IP address 208a of the NAT router 206a, and the original IP address 202a of the first endpoint 200, step 306. Preferably, this mapping is recorded in a mapping table, as illustrated in Fig. 4. It will be appreciated that source IP address in the header of the message will depend on a path traversed by the signalling message from the first endpoint 200 to the second endpoint 204, and in general, is the IP address of the most recently traversed NAT router 206a prior to delivery of the signalling message to the second endpoint 204.

In the preferred embodiment, the first endpoint 200 transmits a signalling message to the second endpoint 204 for each available interface associated with the first endpoint 200. In the present case, the first endpoint 200 is also associated with an available interface having an IP address of 202b. Thus, the first endpoint 200 transmits a second signalling message to the second endpoint 204, step 308. Again, the second signalling message includes a unique identifier of the first endpoint 200, and a source IP address, 202b, associated with the second interface of the first endpoint 200.

As the signalling message traverses the NAT router 206b, the NAT router 206b modifies a source IP address in the header by replacing the source IP address 202b of the first endpoint 200, with an IP address 208b of the NAT router 206b, step 310, and relays the message to the second endpoint 204, step 312.

On receiving the signalling message at the second endpoint 204, the agent creates an entry in the mapping table, as illustrated in Fig. 4, to record the mapping between the source IP address in the header of the message, namely, the IP address 208b of the NAT router 206b, and the original IP address 202b of the second interface associated with the first endpoint 200, step 314.

In the preferred embodiment, once signalling messages for each available interface have been transmitted from the first endpoint 200 to the second endpoint 202, a multi-homing protocol connection is next established. This is preferably achieved using SCTP. However, it will be appreciated that any suitable multi-homing protocol, such as Multi-Path TCP, may be employed.

Referring again to Fig. 3, the first endpoint 200 transmits an SCTP INIT message, from the interface whose IP address is to represent a primary address of a multi -homing association, which is, in this case, the first interface having IP address 202a, to the agent at the second endpoint 204, to thereby initiate establishment of the multi- homing protocol connection, step 316. The source information in the IP header of the SCTP INIT message is modified by the NAT router 206a, step 318, and the SCTP INIT message is routed to the second endpoint 204, step 320. In the preferred embodiment, the multi-homing protocol configuration at the client or first endpoint 200 is configured to include in the establishment request or SCTP INIT message, only the IP address of the primary or first interface having IP address 202a. No other addresses of available interfaces are included in the establishment message. This involves a deviation from the default SCTP behaviour of including all available IP addresses associated with the first endpoint 200 in the SCTP INIT message during association establishment. In this case, since the SCTP INIT message does not include any other IP addresses associated with other interfaces of the first endpoint 200, on receipt of the SCTP INIT message at the second endpoint 204, the other IP addresses are not included as part or elements of the established association.

On receipt at the second endpoint 204 of the establishment message, the association for the client or first endpoint 200 is established, and the source IP address in the header of the SCTP INIT message, namely, the IP address 208a of the NAT router 206a, is recorded as the primary IP address of the association, step 322. The second endpoint 204 sends an acknowledgement message, INIT-ACK, indicating receipt of the SCTP INIT message to the NAT router 206a, step 324, which modifies the destination information in the header of the acknowledgement message to indicate the IP address 202a of the first endpoint 200, step 326 and routes the acknowledgement message to the client, step 328.

It will be appreciated that in the preferred embodiment, the SCTP INIT message includes a cookie, created at the first endpoint 200. The cookie includes information by the second endpoint 204 to establish the association, and possibly information to authenticate the cookie as being originated for the second endpoint 204, and a time stamp, with an expiration deadline.

On receipt of the acknowledgement message from the second endpoint 204, a cookie echo message, COOKIE- ECHO, for the second endpoint 204 is transmitted from the first endpoint 200, step 330. The source IP address of the cookie echo message is modified to the public IP address 208a at router 206a, step 332, and the cookie echo message is forwarded to the second endpoint 204, step 334.

When the second endpoint 204 receives the cookie echo message, it examines the previously received cookie to ensure the cookie is authenticated, correct and has not expired, step 336. If these conditions are satisfied, a cookie acknowledgement message, COOKIE-ECHO, is transmitted to the IP address of the NAT 206a, step 338. The NAT router 206a modifies the destination address to direct the a cookie acknowledgement message to the first endpoint, step 340, and routes the cookie acknowledgement message to the first endpoint 200, step 342.

In this way, the SCTP INIT message, the INIT-ACK message, the COOKIE-ECHO message and the COOKIE- ACK message form a four-way handshake, which assists in mitigating security attacks.

Once the association has been successfully established through the primary IP address 202a/208a, the first endpoint 200 transmits an association configuration message to request the second endpoint 204 to add to the association, a second available interface IP address, 202b, step 344. The association configuration message includes within the body of the message, the interface IP address 202b. The interface IP address is also included in the header of the association configuration message as the source of the association configuration message. As the message traverses the NAT router 206a, the source address in the header is replaced with the IP address 208a of the NAT router 206a, step 346. However, the IP address 202b provided in the body of the association configuration message is not modified by the NAT router 206a.

The NAT router 206a then relays the association configuration message to the endpoint 204, step 348. The agent at endpoint 204 is arranged to catch or capture the association configuration message before it reaches the upper layer multi-homing protocol stack.

If the agent instead allowed the association configuration message to proceed to the SCTP stack, the IP addresses 202b provided within the body of the association configuration message would be added to the association, and since this IP address is not reachable from the agent endpoint 204, it could not be used successfully, as described above.

However, in accordance with the preferred embodiment of the invention, the agent at the second endpoint 204 captures the association configuration message and retrieves from the body of the association configuration message, the IP address 202b of the second interface associated with the client endpoint, step 336. The agent consults the mapping table as illustrated in Fig. 4, created from the signalling messages to determine a suitable and routable IP address to which the second interface is to be mapped, step 350. The agent then replaces the IP address 202b of the second interface provided within the body of the association configuration message with its mapped IP address, 208b, which corresponds to the IP address of the NAT router 206b, through which the second signalling message from the second interface was routed, step 350.

The agent then releases the modified association configuration message and it is passed to a local SCTP stack on the second endpoint 204, where the IP address 208b is added to the association. As this address is reachable from the second endpoint 204, the address can be successfully utilised as an alternative route to the first endpoint 200. Thus, should it be desired to communicate with the client at the first endpoint via the second interface, any messages may be transmitted from the second endpoint 204 to the IP address 208b of the NAT router 206b, where the header information will be modified to indicate the destination IP address 202b of the second interface of the first endpoint 200, and the message will be successfully routed to client.

In the case that an additional third interface associated with the first endpoint 200 becomes available after the association has been established, this third interface can also be added to the association using the method of the present invention.

In the preferred embodiment, when a new interface becomes available at the first endpoint, out-of-band signalling via path 202c-206c-208c is employed in order to record an entry in the mapping table, as illustrated in Fig. 4, associating the new interface's IP address, 202c, and a public routable address 208c.

Thus, the client at the first endpoint 200 transmits a third signalling message to the second endpoint 204 to establish an out-of band signalling session with the agent at the second endpoint 204, step 352. In the preferred embodiment, this signalling session uses an ordinary transport protocol, which need not necessarily be a multi- homing protocol, such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP).

The third signalling message includes a unique identifier of the first endpoint 200 and an original IP address 202c indicating a source IP address of the third interface of the first endpoint 200. Preferably, the unique identifier of the first endpoint 200 and the original IP address 202c are provided within the body of the signalling message.

As the signalling message traverses the NAT router 206c, the NAT router 206c modifies a source IP address in the header by replacing the source IP address 202c of the first endpoint 200, with an IP address 208c of the NAT router 206c, step 354, and the NAT router 206c routes the signalling message to the second endpoint 204, step 356.

On receiving the signalling message at the second endpoint 202, the agent creates an entry in the mapping table, as illustrated in Fig. 4, identifying a mapping between the source IP address in the header of the message, namely, the IP address 208c of the NAT router 206c, and the original IP address 202c of the first endpoint 200, step 358.

The first endpoint 200 then transmits, from the first interface 202a an association configuration message to have the third available interface IP address 202c, added to the association, step 360. The association configuration message includes within the body of the message, the interface IP address 202c. The interface IP address is also included in the header of the association configuration message as the source of the association configuration message. As the message is relayed through NAT router 206a the source address in the header is replaced with the IP address 208a of the NAT router 206a, step 362. However, the IP address 202c provided in the body of the association configuration message is not modified by the NAT router 206a.

The NAT router 206a then relays the association configuration message to the second endpoint 204, step 364. As discussed previously, the agent at endpoint 204 is arranged to catch or capture the association configuration message before it reaches the SCTP stack and retrieve from the body of the association configuration message, the IP address 202c of the third interface associated with the first endpoint, step 366. The agent consults the mapping table, as illustrated in Fig. 4, which was created from the signalling messages, to determine a suitable and routable IP address to which the third interface is to be mapped, step 366. The agent then replaces the IP address 202c of the second interface provided within the body of the association configuration message with its mapped IP address, 208c, which corresponds to the IP address of the NAT router 206c, through which the third signalling message from the third interface was routed, step 366.

The agent then releases the modified association configuration message and it is passed to a local SCTP stack on the second endpoint 204. The local SCTP stack adds the IP address 208c to the association. As this address is reachable from the second endpoint 204, the address can be successfully utilised as an alternative route to the first endpoint 200. Thus, should it be desired to communicate with the first endpoint via the third interface, any messages may be transmitted from the second endpoint 204 to the IP address 208c of the NAT router 206c, where the header information will be modified to indicate the destination IP address 202c of the second interface of the first endpoint, and the message will be successfully routed to client.

In a second embodiment of the present invention, as with default SCTP behaviour, the SCTP EMIT message from the first interface associated with the first endpoint 200 is arranged to include some or all available interface IP addresses and is transmitted to the endpoint 204. Although the source address of the SCTP EMIT message is modified from 202a to 208a by the NAT 206a, the IP address 202b of the other available interfaces associated wit the first endpoint 200 and provided within the body of the SCTP EMIT message remain unchanged. In this embodiment, the agent at the second endpoint 204 is arranged to capture the SCTP EMIT message and delete from the body of the SCTP EMIT message, the IP address 202b of the second and any other interfaces associated with the first endpoint 200 provided there within. The agent then releases the SCTP EMIT message and passes the SCTP EMIT message to the SCTP stack for processing as normal.

In a third embodiment, again and as with default SCTP behaviour, the SCTP EMIT message from the first interface associated with the first endpoint 200 is arranged to include some or all available interface IP addresses and is transmitted to the endpoint 204. Although the source address of the SCTP EMIT message is modified from 202a to 208a by the NAT 206a, the IP address 202b of the other available interfaces associated wit the first endpoint 200 and provided within the body of the SCTP EMIT message remain unchanged. In this third embodiment, the agent at the second endpoint 204 is arranged to capture the SCTP EMIT message and retrieve from the body of the SCTP EMIT message, the IP address 202b of the second and any other interfaces associated with the first endpoint 200 provided there within. The agent consults the mapping table as illustrated in Fig. 4, created from the signalling messages, to determine a suitable and routable IP address to which the second interface is to be mapped and replaces the IP address 202b of the second interface provided within the body of the association configuration message with its mapped IP address 208b, which corresponds to the IP address of the NAT router 206b, through which the second signalling message from the second interface was routed. The agent then releases the modified association configuration message and it is passed to a local SCTP stack on the second endpoint 204. The local SCTP stack then creates the association including the IP address 208b as a secondary interface for the first endpoint 200.

In a fourth embodiment, again and as with default SCTP behaviour, the SCTP EMIT message from the first interface associated with the first endpoint 200 is arranged to include some or all available interface IP addresses and is transmitted to the endpoint 204. Although the source address of the SCTP EMIT message is modified from 202a to 208a by the NAT 206a, the IP address 202b of the other available interfaces associated with the first endpoint 200 and provided within the body of the SCTP EMIT message remain unchanged. In this fourth embodiment, the agent at the second endpoint 204 does not intercept the SCTP EMIT message and it is passed to the SCTP stack. Accordingly, an association is established which includes the original and un-routable IP addresses of the second and/or additional interfaces as secondary addresses for the first endpoint 200. However, when the subsequent association requests for each of the additional interfaces are intercepted by the agent at the second endpoint 204, the IP address 202b of the second or additional interface provided within the body of the association configuration message is replaced with its mapped IP address, 208b, and the modified association request is released. On receipt of the modified association request at the SCTP stack, the entry in the association for the second or additional interface as set up or entered when the association was established is simply overwritten with the new and mapped IP address.

In any of these variations of the preferred embodiment, further newly available interfaces may thereafter be added to the association by the transmission of out of band signalling messages and association configuration messages as described above.

Multi-homed protocols, in general, assume that all interfaces in a specific association connect to a router, such as a gateway, on a same port, identified by a port number. However, when multiple clients at different endpoints connect to a NAT router, such as a NAT gateway, on a same port, the NAT router carries out a port mapping and the NAT router will modify a source port number of the client's traffic so that traffic directed to each client in the downstream can be differentiated.

In order to prevent the NAT router from providing each interface of the association with a different port number, in the preferred embodiment, the present invention further provides a port negotiation mechanism as illustrated in the message flow of Fig. 5, to allow for the allocation of a specific port to each association.

As illustrated, and in addition to the steps carried out as depicted in Fig. 3, on reception of the first signalling message from the first interface of the first endpoint 200, the agent at the second endpoint 204 deterministically assigns a port number to the client and records the port number as being associated with the client, step 500. The agent at the second endpoint 204 transmits the suggested port number to the client at the first endpoint 200, preferably within a body of an acknowledgement message, step 502. As the acknowledgement passes through the NAT router 206a, the NAT router performs traditional IP address and port translations, step 504, but the body of the acknowledgement message remains unmodified and is passed to the first interface of the first endpoint 200, step 506.

The first endpoint 200 is arranged to retrieve the port number from the acknowledgement message, step 508, and to thereafter utilise the suggested port number when communicating with the second endpoint 204 from the first interface of the first endpoint 200.

Similarly, on reception of the second signalling messages from the second interfaces of the first endpoint 200, the agent at the second endpoint determines previously assigned the port number for the client, step 510 and transmits the port number to the second interface within the body of an acknowledgement message, step 512. The acknowledgement message passes through NAT router 206b where traditional IP address and port translation is carried, step 514, and is routed to the second interface of the first endpoint 200, step 516.

Again, the first endpoint 200 retrieves the port number from the acknowledgement message, step 518 and thereafter utilises the port number when communicating with the second endpoint 204 from the second interface of the first endpoint. As the port number is unique to each first endpoint 200 connected through the same NAT router and accordingly, a traditional NAT will have no need to perform any source port number modification to packets passing through it from the first endpoint 200 to the second endpoint 204.

The invention is not limited to the embodiment(s) described herein but can be amended or modified without departing from the scope of the present invention.