Subject: Multihomed mobile host and address scoping issues

From: "Eng Se-Hsieng" <[email-masked]>
Date: Tue, 8 Apr 2003 19:57:27 +0800

Dear all,

We are trying to set up a multihomed host with two private 172 IPs on
two networks using lksctp and there is some difficulty in setting up the
association. After discussion on the lksctp mailing list, it was found
that that this might be due to the address scoping rules.

According to the v4 address scoping rules, the source (Host A) with a
Level 3 private IP address is not able to initiate a connection with a
destination (Host B) with a Level 4 global IP address. 

However, the case of one endpoint being behind a NAT is resolved in RFC
3257 by not including a source address in the INIT chunk. The source
address in the IP header would then be used as the only destination
address for this association. Currently, lksctp does not allow the INIT
to be sent at all and a preliminary bug report has been opened.

    +-------+   +----------+      *~~~~~~~~~~*           +------+
    |Host A |   |    NAT   |     *   Cloud    *          |Host B|
    |172.1  +---+     |    +-----+           --+---------+ 132  |
    |private|   |          |     *             *         |fixed |
    |  IP   |   |          |      *           *          |  IP  |
    +-------+   +----------+       *~~~~~~~~~*           +------+

Eventually however, we would like to set up the following multihomed
client where Host A could have 1 private IP address on a WLAN network
and another private IP address on the GPRS network. 

    +-------+   +----------+      *~~~~~~~~~~*           +------+
    |Host A |   +   NAT X  |     *            *          |Host B|
    | 172.2 +---+172.1|5.2 +-----+             +---------+ 132  |
    |	      |   +----------+    *    Cloud     *         |      |
    |       |   +----------+    *              *         |      |
    |	      |   |   NAT Y  |     *             *         |      |
    | 172.5 +---+172.1|6.2 +-----+            *          |      |
    +-------+   +----------+       *~~~~~~~~~*           +------+

In this case, not including any source address in a INIT chunk from HOST
A would allow only one address to be used.

It seems that Dynamic Address Reconfiguration would not allow the second
address to be added as the second address cannot be used as a source
address until the ADDIP process is complete. Thus the destination
endpoint never receives an IP header listing the second address and the
association would not be able to use the multihomed configuration.

Does this fall into the black hole condition? Yet the above seems a very
likely situation, especially for mobile hosts. 

We would be most grateful for any advice. Thank you.

Regards,
Se-Hsieng

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 8 Apr 2003 12:49:53 -0500

On 4/8/03, Eng Se-Hsieng wrote:

>
>Eventually however, we would like to set up the following
>multihomed client where Host A could have 1 private IP
>address on a WLAN network and another private IP address
>on the GPRS network. 
>
>In this case, not including any source address in a INIT
>chunk from HOST A would allow only one address to be used.
>

The above scenario has several challenges.

First, it inverts the normal challenge of a NAT box. Typically
a single NAT box making multiple internal hosts appear to be
part of a single virtual host. Here two distinct NAT boxes are
representing the same host, further they want the outside
world to know they are the same host even with different
IP addresses.

Some specific challenges:

- Can NAT Y be guaranteed to use the same port as NAT X?
  Normally selection of external ports on a NAT is not
  deterministic. Typically, the best that is offered
  is to use the port supplied by the internal host --
  as long as it is not already in use.
  
  If 172.7 is talking to HOST C via NAT Y, the desired
  port may already be assigned to it. Unless NAT Y
  is doing 1 to 1 matching of internal addresses with
  external addresses this will be a problem.
  
- Can the public address via NAT Y be known without
  first establishing the association in a way visible
  to NAT Y?
  
  I am assuming that NAT Y has support for SCTP, but
  that the support is basically a translation of TCP
  primitives. That is, the NAT was adapted to recognize
  new methods of spotting a new "connection" and its
  termination, and probably that there is a new port
  space. But I would not assume that it did more without
  being told so in advance.
  
  In particular, I would not assume that it would recognize
  a packet that is part of an association established
  via NAT X.
  
Ideally, NAT Y would support an interface allowing reservation
of an external port. Host A would ask NAT Y to simply create
a port mapping for 172.5 port J, and then use the value
supplied. Many NATs support this functionality, for the
purpose of hosting virtual servers within a firewall.

Having made the reservations on both NAT X and Y, the
INIT can be sent listing the public addresses in the
Address List.

Caitlin Bestler
http://asomi.com/CaitlinBestler/