Subject: RE: Multihomed mobile host and address scoping issues

From: "Eng Se-Hsieng" <[email-masked]>
Date: Sat, 12 Apr 2003 15:15:06 +0800

Hi,

My university WLAN does not support UPnP. I am trying to see if there is any way we can reserve an external port.  Any suggestions would be appreciated.

Does the reference implementation provided with Randall's book provide the ADDIP/DELIP extension?

The below scenario seems very possible in the wireless world. I wonder if Mobile SCTP covers this scenario?

I am having some problems installing it on Linux Redhat 8.0. "gmake" or "make" returns No targets. Stop. Is some configuration necessary?

Thank you.

Regards,
Se-Hsieng

-----Original Message-----
From:	Caitlin Bestler [mailto:[email-masked]]
Sent:	Wed 4/9/2003 1:49 AM
To:	[email-masked]
Cc:	Eng Se-Hsieng
Subject:	Re: Multihomed mobile host and address scoping issues
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. 
>
>    +-------+   +----------+      *~~~~~~~~~~*           +------+
>    |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.
>

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/