Subject: [mobile-ip] Mobile Netwoks in MIPv6

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 30 Mar 2001 02:14:11 +0200

Hello Raj and Phil, 

I've been meaning to suggest this since the San Diego meeting
but never got around to it. 

Thierry Ernst has brought up a valid scenario in which the MIPv6
spec does not work. This is reagrding the support of Mobile 
Networks in MIPv6. 

The scenario and solution are explained in :
http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-01.txt

This draft was presented in Pittsburgh (00) and San Diego (01).
Personally I think this is a good solution and it deserves the 
WG support. 

While we have addressed one aspect of mobile networks 
in HMIPv6. The solution only addresses certain scenarios
(As per my email discussion with Mike Thomas before the
IETF meeting ) and we don't expect every MN with MIPv6 
implementation to support HMIPv6 (of course some won't even 
support the MIPv6 MN functionality which puts a higher
demand on Thierry's draft). 

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). 

Comments ?

Regards,
Hesham

---

From: "T.J. Kniveton" <[email-masked]>
Date: Thu, 29 Mar 2001 18:13:26 -0800

> Hello Raj and Phil,

Since you posted this to Mobile-IP list, I'll take the liberty to assume
you want responses from others than Raj or Phil.

> http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-01.txt

I don't see exactly why this scenario is a problem. As long as the
network is in the routing tables of the home link's routers as having a
next hop of the MR, there's no problem.

This draft states in section 3.2.4:
      When the packet gets to the home
      network, BR checks its routing table to reach SN1. BR has a route
      to the mobile network; MR's home address is the next hop towards
      SN1. . . The HA intercepts
      the packet, but does not have a route to the mobile network.

Why would the BR have a route to the mobile node, and the HA wouldn't?
They are on the same link, so it seems like the HA is not picking up the
same routing info as the BR. This would be a configuration issue.

> If so, you might like to consider this draft as one proposal

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.

-- 
T.J. Kniveton
NOKIA Research

---

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

Hi,

> next hop of the MR, there's no problem.

Yes there is a problem because the prefix of the mobile network is not
the same as the prefix of the MR's home address.

> Why would the BR have a route to the mobile node, and the HA wouldn't?

Both BR and HA have one, and this route is via the MR (i.e. via
int0).    I used the BR to point out the problem.  

Then, the route recorded in the routing table says "route packets which
destination is the mobile network prefix to the MR".   Unfortunately, MR
has moved, what do you do then ?  HA does only know how to encapsulate a
packet which destination = MR, not a packet which next hop = MR.    We
have done the experiment on FreeBSD, has it is described in the draft.

 ---          ---
 |BR|          |HA|
 ---          ---
   |               |
   |               |
 _____________ home link  P1::/64
          |
          | int0 P1::/64
          |
        ---
        |MR|
        ---
         |
         | int1 P2::/64
         |
   __________________  link internal to the home network
      |                     | 
      | int3  P2::64    |  int4 P2::/64
      |                     |
    ---               ---
   | H  |               | R  |
    ---               - --

o The mobile network is attached to the Internet via the mobile router
MR

o MR has (at least) 2 interfaces:
	- int0 points to the home link, and has prefix <P1>
	- int1 points to a link internal to the mobile network and has prefix
<P2>
	
o All addresses in the mobile network have the same prefix P = the
mobile network prefix
	- length P = Lp  /   length P1 = Lp1 / length P2 = Lp2
	- Lp  < Lp2.
	- Lp first bits of P2 = P
	- Lp first bits of P1 <> P
	- Lp fitst bits of P1 <> Lp first bits of P2

o Both BR and HA have an entry in their routing table corresponding to
the mobile network prefix <P2>: this entry says that packets to the
mobile network should be routed to MR via int0.

o HA has received a binding update which says "packets sent to
int0::/128  should be encapsulated".  Then, HA pretends to be int0.  It
gets the packets directed to P2 and those directed to int0.
	- Once HA gets a packet to MR (int0), no problem, encapsulation to MR's
COA.
	- If packet has a destination in the mobile network with prefix P2, HA
won't know what to do with it, because the next hop to P2 is the HA
itself.  It does not know how to handle it because it has only been
instructed to redirected packet sent a 128 bits address, and not to
prefix P.

> same routing info as the BR. This would be a configuration issue.

You may configure your routing tables in a way that it works, but this
is more like a hack.  MIPv6 does not says how to re-route a packet wich
is not sent to the home address.

The problem comes from the information carried in the Binding update
which says "it destination = int0::/128 bits, encapsulate packet to the
MR's coa.  If you allow HA to redirect packets sent to a prefix, it will
work, but you need to specify it in the spec.

> already be handled by whatever routing protocol is used, and the base

There is nothing to do with the routing protocol unless you want to
update the routing tables of all nodes in the AS.    My draft proposes
to use base Mobile IPv6, but we need an extension to specify to the HA
that it should also encapsulate packets intended to nodes in the mobile
network with prefix P2.

Is this clearer ?
Thierry

--
* mailto:[email-masked]  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 30 Mar 2001 16:51:26 +0200

Hi,

> instructed to redirected packet sent a 128 bits address, and not to

I agree that the BU should express more, maybe a flag like "also forward
traffic destined to prefixes behind the MN".

> is not sent to the home address.

But it says what to do with packets that have been intercepted. Please
see below.

> work, but you need to specify it in the spec.

I agree that the spec is not 100% explicit on this. However, I see it
possible to interpret the spec as follows:

The HA's intercepting function is to pick up packets destined to the
MN's layer 2 address. It's ND proxy function will see to that all nodes
on the home link map the MN's int0 layer 3 address to the HA's layer 2
address. This is done by NS/NA mechanisms.

All routers on the home link should know, as you say, to forward packets
to P2::/64 to int0. They will end up in the HA. HA won't drop them,
since they are destined to it's layer 2 address.

At least in BSD, next check in HA is to check if this is a packet to the
HA itself. Since it doesn't have the int0 address configured on one of
its interfaces, it will see if it is forwardable, or drop the packet.

The HA will try to forward it, and would look in its routing tables. It
would have two interesting entries:
	dest P2::/64   use next-hop int0	(determine gateway)
	dest int0      use next-hop MN-tunnel	(determine interface and 
						layer 2 address)
It will end up sending it into the MN-tunnel.

This is not necessarily the exact behaviour of all implementations, but
I would like to see it as the correct conceptual behaviour.

/Mattias

PS. Don't get me wrong. I like your draft.

---

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

Hi,

Thanks to your comments, Mattias.

> traffic destined to prefixes behind the MN".

I think this is not enough.   It would be better to explicitly specify
the said prefix in the BU.    How would the HA knows what is the prefix
behind the MR - I mean, how would it do this if you don't add anything
in the MIPv6 spec and if you strickly follow the spec ?

> possible to interpret the spec as follows:

Hum, interpretation always leaves room for misunderstanding and
misinterpretation ...

> its interfaces, it will see if it is forwardable, or drop the packet.

Agreed.

> It will end up sending it into the MN-tunnel.

Thanks for your clarification.  

If I follow you, you mean that the HA already has all the necessary
information in its routing table to do it right, but that some
implementations might not do it.

I do not exaclty know how algorithms for searching the routing table
really work, but I would think that finding an entry and then searching
for a second one is rather complex and may end up in routing loops.  I
am just wondering.

> I would like to see it as the correct conceptual behaviour.
For sure, the FreeBSD's HA is getting confused.

> PS. Don't get me wrong. I like your draft.
It wouldn't arm me anyway :-) Just trying to fix the trick.

Thierry.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 30 Mar 2001 14:28:59 -0800

> that it should also encapsulate packets intended to nodes in the mobile

Yes, I see what you mean now. Thanks. There are a few problems here:

1. Section 9.6 says to "intercept any packets on the home link addressed to the
mobile node's home address," but doesn't talk about packets where the next hop is
the MR.
  - As Mattias noted, you should be able to insert an entry to the routing table,
through a tunneled RA, to map this prefix to the MN's link-local address, but that
brings us to problem 2:
2. Section 9.6 also says NOT to forward packets destined to the MN'S LL address.
When the MN is a MR, packets for the LL address really need to be forwarded.
  - We could potentially add a rule that the LL packets should be discarded
UNLESS the HA has a routing entry for this prefix to the MR. This is getting very
close to what your draft does.
3. Distributing prefix and routing information when you're away from home seems to
always be messy. What would happen according to your draft when the MR sends
prefix info to the HA, the HA inserts the prefix entry into its routing table, and
then the MN asks for prefix info ("tunneled" mobile RS) from the home agent and
gets that prefix back?

I agree this is a sticky situation, and it's hard to get MRs working, although I'm
open to the idea it may be possible with a few tweaks to the existing draft.

--
T.J. Kniveton
NOKIA Research

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 31 Mar 2001 00:44:14 +0200

> in the MIPv6 spec and if you strickly follow the spec ?

If I read the spec word by word I would end up with my interpretation.
If I read behind the lines maybe I would miss this and think the HA
should only forward packets to the MN itself. I don't think the draft
should need special care for cooperation with every other protocol out
there. It should say as little as possible, with the correct wording.

> for a second one is rather complex and may end up in routing loops.  I

Well, if the MR is at home, what routing table entries would the HA
have? It should have one for the prefix P2::/64 being routed towards
layer 3 address of MR. If this is statically configured or learnt by
routing protocols wouldn't matter. If I am wrong on this please correct
me.
  Next, it would also have a neighbor cache entry for MR, in order to
map layer 3 address to a layer 2 address for delivery of the packet. In
the environment I'm familiar with (KAME) the neighbor cache is
integrated in the routing table, but this is a minor detial.
  Summary, two entries. Same as above, but now with a layer 2 address in
the second entry's next hop field instead of the tunnel pointer.

This has little to do with implementation. I can't see that you could go
around this behaviour in a correctly implemented IPv6 router (such as a
HA).

When the MR moves, the HA can't just wipe out all previous routing table
entries for the MR. It needs to just replace the neighbor cache entry
with the pointer to the tunnel.

Please note that the intercepting consists of two quite separate parts:
1. The ND proxy. To redirect neighbors layer 3 address resoltion to the
HA's layer 2 address.
2. The forwarding and encapsulation. Packets that appear in the routing
process of the HA that are not originated by the HA but destined to the
MR or the network behind the MR are simply forwarded (and ends up being
encapsulated). HA doesn't have to check whether packets are destined to
the network behind the MR by looking in its binding cache. It should
only look in its routing table. 

> For sure, the FreeBSD's HA is getting confused.

Well, you actually need to be aware of this intended behaviour so that
it can be implemented the proper way. I would argue for a clearer
description in the draft.

/Mattias

---

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

> through a tunneled RA, to map this prefix to the MN's link-local address, but that

I'm not so sure that that the MR should tunnel a RA to the HA. Do you
really mean that?

However, it's a whole lot better if the HA's route to P2::/64 uses MR
*global* address, instead of the link-local. It's possible, but maybe
routing protocols don't like other than link-locals.

/Mattias

---

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

> with the pointer to the tunnel.
Ok, this made it clear. I think it should work automatically. But
still, one can make this clear in the draft i guess.

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Sat, 31 Mar 2001 15:31:20 +0200

If one of the questions is this draft (draft-ernst-mobileip-v6-network-01.txt)
should be a WG draft I vote in favor of this.

Regards

[email-masked]