Subject: [mobile-ip] Appndix B of HMIP draft

From: Lewis Adam-CAL022 <[email-masked]>
Date: Tue, 28 Aug 2001 13:55:22 -0500

Something in appendix B of version 4 of the HMIP draft is not clear to me.  The paragraph directly under figure B.1 states:

"Hence, it may not be possible to use addresses
   based on PREFIX_A as source addresses for the MNs."

I agree PREFIX_A will not work as a source address as it would likely be dropped at AR1 due to ingress filtering.  However, won't a source with PREFIX_B also be dropped (this time by the MR) due to the same ingress filtering reasons?  Afterall, MR's PREFIX_A interface would not expect to see packets with PREFIX_B as a source (but this is what is being done in the extended mode with mobile routers).  I assume I am missing something.  Does the MR not pefrom ingress filtering in this scenario?  Does it look at the home address option to verify it is in fact topologically correct?

Please clarify.

Thanks,

Adam

Adam C. Lewis 
Senior Engineer 
Advanced Technology & Strategy 
Global Technology Development Group 
Commercial, Government, and Industrial Solutions Sector 

1301 E. Algonquin Road 
IL02/Rm. 509 
Schaumburg, IL 60196 
Email: [email-masked] 
Phone: (847) 576-8489 Fax: (847) 576-9018

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 29 Aug 2001 16:08:36 +0200

> I agree PREFIX_A will not work as a source address as it would likely be dropped at AR1 due to ingress filtering.  However, won't a source with PREFIX_B also be dropped (this time by the MR) due to…
	=> Thanks for catching that despite a cryptic figure (we'll fix that figure
	in the next revision). 
	There are different ways we can handle this:

	1. The MR is aware of the mobility scenario (it does know 
	    what's happening because it sets theT flag in the 
	    MAP option) so it doesn't ingress filter on the PREFIX_B address

	2. We make sure that the MN uses RCoA (from the further MAP) 
	    as a source and the MR MUST NOT ingress filter that prefix.

	3. The MR does the same as 1 and tunnels outgoing packets to the 
	    further MAP (fixed MAP). 

	I prefer 3 andwould try to avoid 1 as much as possible. 
	What do you think ?

	Hesham

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 29 Aug 2001 15:30:55 -0500

Hesham,

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, August 29, 2001 9:09 AM
To: [email-masked]'
Subject: RE: [mobile-ip] Appndix B of HMIP draft

	Hesham

----
I agree option 1 should be avoided.  The problem I have with both options 2) and 3) is that they both assume their is a further MAP.  It is very possible I think that somebody might want to use the value-added ability of HMIP to support a mobile router/network, without deploying a full HMIP network.  I think the two should be able to stand alone.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 30 Aug 2001 10:34:25 +0200

> I agree option 1 should be avoided.  The problem I have with both options 2) and 3) is that they both assume their is a further MAP.  It is very possible I think that somebody might want to use the…
	=> I agree. However, the "further" MAP is only needed as a tunnel end point. 
	So to replace it you need to:

	1. Have an IP address for another router	(easily solved)

	2. That router has to trust you and forward your original packet that
	    wouldn't have gone through the ingress filter. This 
	    trust is implicit in the further MAP by virtue of the 
	    BU (I know this is questionable but some extensons 
	    can be made to allow this). 

	So the second point is not tricky to solve but it requires 
	a carrier. Having it as a further MAP allows the carrier to
	be a BU. 

	Of course you can also just reverse tunnel to the HA !
	This will solve it but for a price.

	Hesham

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Thu, 30 Aug 2001 11:45:17 -0400

Hi,

	I wanted to solicit a response from anyone interested in working on:

	· Inter-Domain Mobility Management (mobility between two
administrative networks).

	This could be viewed as higher-level mobility management (sometimes
called "roaming").
	Solutions to this problem have ben presued in other organizations,
3GPP, but I am not certain 
	of anything being done in the IP-layer. 
	
	If anyone is interested I would be glad to discuss further, either
on the mailing-list, or off-line.

	Thanks.

	-Sharif.