Subject: RE: [mobile-ip] Mobile Netwoks in MIPv6

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 30 Mar 2001 18:48:40 +0200

> > So do you think the draft or at least the problem should
> > be considered as part of the charter ?
> > If so, you might like to consider this draft as one proposal
> > (a good one IMHO).
> 
> Can you please give an example of how a network which is properly
> configured would fail in this circumstance? It seems like it would
> already be handled by whatever routing protocol is used, and the base
> Mobile IPv6 spec.
> 
	=> Hopefully this would answer your previous comments 
	(that I removed). 
	When the HA forwards packets to MNs behind the MR, 
	it doesn't address thse packets to the MR. Since the MR
	has "gone", no one is advertising reachability to it's 
	subnet. So the HA will not know what to do with it. 
	Thierry mentioned in his presentation that he proved 
	this case in thei labs.

	We need to make sure the MR sends a BU for the 
	entire prefix. 

	Hesham

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 30 Mar 2001 09:05:45 -0800 (PST)

>       Thierry mentioned in his presentation that he proved

When MR was at home it was advertising reachability and as soon
as it moved to the foreign link one would expect that to still
happen and this time,  tunneled to HA. If tunnel is yet another
interface, then  the reachability should be advertised, right ?
Why isn't this happening ?

If there were static routes on the Home agent, then this is
not a problem too. Just to make the picture clearer.

-mohan

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 30 Mar 2001 21:12:36 +0200

> Why isn't this happening ?

Indeed, nothing should prevent the MR to advertise reachability to its
the subnets behind it and nobody stated this.    Yes, advertisments
should effectively be tunneled to HA.   (I can not remember if this is
pointed out in the MIPv6 draft or not, or somewhere else;  could someone
say where ?)

The problem comes from what it being recorded in the Binding Cache at
the HA: nothing tells the HA to encapsulate packets sent to the
mobile_network_prefix P2.   If some implementations do it, this is an
interpretation of the MIPv6 specification and would add room for
hacking:  why should the HA encapsulate packets sent to prefix P2 to the
MR's coa if it wasn't instructed to do it ?
 
Any comments on what the HA should be allowed to do ?

> not a problem too. Just to make the picture clearer.

Thierry.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 30 Mar 2001 14:34:30 -0800 (PST)

> MR's coa if it wasn't instructed to do it ?
Agreed that the spec is not clear. HA is defending for "MR" and would
encapsualte packets only meant for MR's home address.  We need
HA to defend for the prefix(es) that is hidden behind MR. Having
the routing entries for those prefixes is not sufficient.

-mohan

---

From: Michael Thomas <[email-masked]>
Date: Fri, 30 Mar 2001 14:50:36 -0800 (PST)

> the routing entries for those prefixes is not sufficient.

   I'm puzzled. I noticed that Theirry's subnet prefix
   is now in the mipv6 binding update in the -13
   draft. Thus, a binding update is nothing more
   or less than a routing update announcing new
   reachability of a given prefix. Normal longest
   prefix match algorithms would assumedly work
   as usual, right?

   Or am I misconstruing the issue?

      Mike

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 31 Mar 2001 01:02:02 +0200

> the routing entries for those prefixes is not sufficient.

The entries in all routers on the home link saying that P2 is behind MR
just don't appear out of thin air. Prefixes are manually configured (or
maybe distributed by some fancy mechanism). Then routing protocols
propagate this information. But the prefix must be manually configured
first, at some point. There's no difference to how P2 was assigned to MR
no matter if MR is mobile or not.

I don't see why you would need to defend this prefix like you do e.g.
for DAD for the MR's home address.

/Mattias

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 30 Mar 2001 15:10:53 -0800 (PST)

>    prefix match algorithms would assumedly work
Could you point out the section ?

Binding update packets contain the home address option from which
you get the home address and a Care of Address either in the
source address or in a sub-option. It tells the home agent that
defend for this home address and tunnel the packet to the
care of address. In this case, it *will* tunnel only if it
sees a packet destined to MR's home address. In the example
described, the packet's destination address is not the
MR's home address. The only issue i have is, what tells
HA to tunnel this packet ?

-mohan

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 30 Mar 2001 15:20:21 -0800 (PST)

> Could you point out the section ?

There is a prefix length field. You are correct. But the definition
is slightly different. Home Agent forms other addresses using
the interface identifier present in the home address of the option.
But nothing says it defends for the prefix.

-mohan

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 30 Mar 2001 15:31:15 -0800 (PST)

> no matter if MR is mobile or not.
I never said anything about prefixes appearing out of thin air.
I think the spec is not clear enough. So, just having the
routing information for all the prefixes behind MR is not
sufficient.

> for DAD for the MR's home address.
Look at the steps involved :

1) MR moves to the foreign link and asks HA to defend for its home
   address.

2) Packet from some CN goes toward HA. Reading 9.5 and 9.6 sections
   of the draft says that it will encapsulate only for packets
   destined to the MR's home address. Any packet for which MR
   is the router, it will try to send it to MR. Hhmm MR itself is
   not home. So should it encapsualte ? But it is not defending
   for those addresses.

I agree that we can clarify the existing draft rather than having
another draft.

-mohan