Assume a mobile-ip daemon that can do the following:

assumptions:
1. do nothing that turns routing control over to 3rd
parties.  If you cannot do that, minimize control.
E.g., asking the FA to route for you back home with
a reverse tunnel is something you should do yourself.

2. we can dynamically distinquish between our 3 basic
scenarios.  How?  if at a FA, we hear a FA beacon.
	We can probe for FAs.
	if not at a FA, we try dhcp.  If dhcp works,
	we look at the kind of address we got.  If private,
	we assume NAT. 

	Rough idea:

	1. hear FA beacons
	2. if none, probe for FAs
	3. OR probe using dhcp for dhcp servers
	4. if none of the above, goto 1 
	5. if dhcp server, note kind of dhcp address

3. we want to impose MN/HA two-way IPSEC tunnels as an option.

suggestions:
1. get rid of FAs or at least admit that they may not exist.

scenarios:

1. normal mobile-ip routing; i.e., "triangle routing" 

ha ---------------------> fa ---> mnd

The mn may or may not tunnel back to the HA.

Observation:
	FAs are not likely to be widely deployed.
	They are certainly useful for more rapid handoff however.

security:
	FA systems will not work with non-local MNs unless
	they support reverse tunneling protocol.

-----------------------------------------------------

2. dhcp-based MIP.  The mn uses dhcp to get a local COA
and does not use a FA.  FAs are rare in the real world. 

ha --------------------->  mnd
   <---------------------

2.1 ha to mn
	ip 			{ip datagram}
	ip src = ha		  ip src = CH
	ip dst = coa		  ip dst = MN fixed ip
	   np = 4

2.2 mn to ha

	ip			{ip datagram}
	ip src = COA		 ip src = CH
	ip dst = HA		 ip dst = MN fixed ip
	   np = 4

IPSEC:
	dynamic IKE possible with outer IP header, based on say
		user@dns.  Also could be based on NAI

	static IPSEC not possible with outer IP header, because COA
		is not predictable.   

	static IPSEC possible on inner IP header.  
		append additional tunnel-mode header, IP ESP,
		between the two IP headers above.  
		This version can use IKE too of course
TBD: need a better name for these two than dynamic/static

		IP	 IP		ESP	ip datagram
		coa	 ipsec, mn/ha

	observation: dynamic IKE form is a better idea as less
		expensive.  It gives us

	IP 		ESP  (the rest)
	src = coa
	dst = HA

security:
	COA allows us to evade ingress/egress firewall filters.
			
-----------------------------------------------------

3. nat/dhcp-enabled MIP. The mn is behind a nat box,
and uses IP/UDP tunnels to talk to the HA.

ha --------------------->  mnd
   <---------------------

3.1 ha to mn
	ip            udp    	mip extension	{ip datagram}
	ip src = ha   src=434	 type != 1/3     ip src = CH	  
	ip dst = coa  dst=434	   np=4          ip dst = MN
	   np = UDP

	note: UDP port dst may NOT be 434 if in use at NAT box.  

3.2 mn to ha (note nat box will modify this)
	ip            udp    	mip extension	{ip datagram}
	ip src = DC  src=434	 type != 1/3     ip src = MN
	ip dst = ha  dst=434	                 ip dst = CH
	   np = UDP

	note: DC is ip address that is private, and will be changed
	by the nat box.  DC must be coa allocated via dhcp or nat box
	will not know how to behave.

	note: udp src port may be changed by nat box.

	ipsec:

	1. we cannot impose IPSEC between the 1st ip header and the
	udp header, as the nat box must see the udp header.

	2. we can only impose IPSEC after the udp header, and
	before the ip datagram.  The static solution from
	non-NAT dhcp will work. 

-----------------------------------------------------

TBDs:
1. draw packet formats in all cases.
2. draw IPSEC possibilities in all cases.

Proposal:

Implement 2 and 3 with MIP.