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

From: Thierry Ernst <[email-masked]>
Date: Fri, 06 Apr 2001 15:08:17 +0200

[sorry - yet another repost from Wednesday]

> > Isn't it always the case that a mobile node behind a
> > mobile router, that the mobile router must be the
> > mobile host's home agent?
> >
>         => Well, don't think so. It may be the case but there is no
>         need to require it.

Agree.

> >  If the mobile router moves,
> > wouldn't that cause the mobile host's BU to the
> > other home agent to become stale?
> >
>         => Not if the other mobile updates its HA with a
>         new location. I mean if you just rely on the MR
>         updating its HA, that would still work but
>         doesn't really give you route optmisation.

Right.

>         Plus the MN may go somewhere else,
>         ie. leave the MR's subnet.

This is yet another issue.

Thierry.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 6 Apr 2001 08:52:01 -0700 (PDT)

> >         doesn't really give you route optmisation.

  Yes, but how does the MN behind the MR *know* that
  MR changed its CoA?

  A related question: if it's just a non-mobile host
  behind a mobile router, what causes those hosts
  to change their home address destination option?
  In fact, how did they know that they needed to
  use it in the first place?

  There are some pretty deep and fundamental questions
  lurking here. Namely, is mobility transparent to 
  non-mobile hosts and if so, why? We also need to
  consider what this means in the face of
  renumbering which in many respects is mobility 
  (flattening) in disguise.

	 Mike

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 06 Apr 2001 18:11:31 +0200

>   Yes, but how does the MN behind the MR *know* that

Why should he ?

>   use it in the first place?

Who ever said that the non-mobile host behind MR change their home
address ?

One of my point is that mobility of MR should be transparent to all
hosts behind the MR.  I thinks it makes sense.

>   (flattening) in disguise.

Renumbering is not to happen at a rate as important as mobility, then
it's not the same issues.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 6 Apr 2001 09:25:33 -0700 (PDT)

> >   Yes, but how does the MN behind the MR *know* that

   If you want an optimized route, MN needs to know
   send a BU to CN as well.

 > Who ever said that the non-mobile host behind MR change their home

   If a host behind a MR doesn't know about its
   mobility, it will place its home address into
   the source address in the IP header. This 
   could cause it to fail RPF checks just like
   MN's. 
  
   This is the problem. The overall solution is
   not clear.

 > hosts behind the MR.  I thinks it makes sense.

   There are tradeoffs which need to be weighed. I
   too favor transparency, but it is not clear 
   whether that is, in fact, the right answer.

 > it's not the same issues.

   All I'm saying is that renumbering and mobility
   are related at a fundamental level and need to
   be considered together.

		 Mike

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 06 Apr 2001 19:23:49 +0200

>    If you want an optimized route, MN needs to know

Not necessarily. It depends on the solution adopted to support MR.   The
MN can tell its CNs it is located in the mobile network whereas the MR
can tell them where is the MR.

>    could cause it to fail RPF checks just like

Then the MR can encapsulate the packet to the CN.  

>    This is the problem. The overall solution is

Agree, but as already said, the draft does not pretend to solve to whole
issues.  It addresses one of the issue and is meant to open the
debate.   If there is a debate, this means there is something that needs
to be fixed.    Then, from your last sentence, I guess you agree that
Mobile Routers and Networks need to be addressed in a separate draft. 
This is a good point.
 
>    whether that is, in fact, the right answer.

I agree.  I have weighed it and I came to the idea that transparency is
an important constraint.  My solution is to keep mobility transparent to
the nodes behind the routers; this is surely not the only solution, but
this is the one I favor.

>    are related at a fundamental level and need to

I agree to this point and won't be against the idea that someone writes
something about this to clarify.

Thierry.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 06 Apr 2001 20:58:42 -0700

Theo has done a good job of summing it up here. Network renumbering would be
perfect for this situation, but it was never designed for this. Although it
could probably be made to work if you could control all the implementations
of nodes behind the MR, in practice it would be a hairy situation,
especially because renumbering has a 95% chance of closing all open
connections from each machine, and destroying a lot of application state. If
handoffs occur frequently, the nodes would be almost unusable. Thus, we
should probably point in one of the other directions under discussion.

Another possibility is for the MR to muck with the IP headers of forwarded
packets from the prefix, putting the MR's CoA in the From field, and
inserting a home address option with the other node's address (original Src
addr). Ugly but I think it would work. This would cause triangular routing
of course.

--
T.J. Kniveton
NOKIA Research

Theo Pagtzis wrote:

> Thierry,
>
>   Having looked in detail the issue of mobile routers in HMIP
>
> I need to agree on some common understanding and expand further..
>
> We have the situation of a mobile node that moves. That MN has multiple
> interfaces. One of this interfaces is attached to a visiting link (gets
> connected to the world), obtains a CoA by whatever extensions. The rest
> of its interfaces serve routing of packets for different attached
> subnets with (for this discussion) fixed nodes.
>
> The MN will be alternatively described as a Mobile Router (MR).
>
> Now when the MR is moving as the PoA for an aircraft and its nodes
> inside, what would happen is that the interface attaching to the world
> will obtain a CoA.
>
> Now that CoA has a prefix. This prefix most probably complies with the
> prefix aggregation scheme of IPv6 for that domain.
>
> That implies to me that when an MR attaches to a new PoA it must trigger
> RENUMBERING to its all of the rest of its interfaces (excluding the one
> that got the CoA). The reason? all interfaces must comply with the same
> prefix; otherwise the border router will not know how to route packets
> to the old prefix, which by the way would routed by the OLD border
> router.
>
> That implies to me that :
>
>      movement of the MR will trigger network renumbering for all
> attached subnets behind that MR simply because of the router/prefix
> aggregation requirement. This is by the way one of the strong points of
> IPv6 for network renumbering per domain.
>
>       The renumbering to the attached subnets under the MR, will also
> trigger a change of the current CoA for all hosts (fixed or mobile
> inside the vehicle). That will bring the entire branch (vehicle) inline
> with the prefix of the visiting domain of the MR. That means to me that
> a movement of an MR will diffuse as a ghost movement of an host
> underneath it.
>
>     Movement of the MR in effect triggers a ghost handoff of the MN. Why
> ghost? The host did not move a single bit but had to change its prefix.
> The semantics of the BU are not decoupling movement of a MN from
> movement of the whole domain (or subdomain which in this case is a
> vehicle). The BU sent out will signal the change of the previous (p)CoA
> to a new (n)CoA. As such for the CNs this will look like a movement of
> the MN.
>
> To this point I would like to differentiate between two dimensions of
> movement.
>
> 1) apparent  (what I have discussed above)
> 2) actual      (the MN does decide to move within the aircraft/spaceship
> (see babylon 5 :) here things complicate a lot. This is so because as if
> the renumbering was not enough, the MN will have to send an extra BU per
> actual local movement. Here a hierarchical scheme should save the
> day...(I am studying which)
>
> The question that remains here is
>
>      1) is renumbering fast enough to effect the semantics of a handoff
> (that is potentially seamless). If not, renumbering will bring us to
> square one for seamlessness...
>      2) an MN has no direct means of discovering that a net renumbering
> is required so that it can solicit and as a result speed it up. So if we
> rely on timeouts and intervals here the handoff is not that fast...
>
> Instead of renumbering I would like to ask whether it is possible to ask
> the routing engine on the border router to transfer routing state for
> the attached subnets under the MR. Would that mean effectively host
> routes for the MR (implicit for the subnets underneath it?).
>
> From the perspective of route/prefix aggregation this should go
> immediately down the drain in my view but I wanted to erify that with
> someone before excluding it from the solution space. The reason is that
> for transient routind state (the vehichle and thus MR, will move soon to
> another domain so what is the point to aggregate here ..) (yes we want
> to shrink the routing table, but we could allow for a temporal
> inflation..couldn't we)
>
> In terms of security I think renumbering should be pretty safe since it
> is effected locally and does not diffuse upstream. Only from the MR and
> below.
>
> Theo
>
> UCL/ Mobile Systems
>
> Thierry Ernst wrote:
>
> > Michael Thomas wrote:
> > >
> > > Thierry Ernst writes:

---

From: Michael Thomas <[email-masked]>
Date: Fri, 6 Apr 2001 14:44:51 -0700 (PDT)

Where I always get stuck on this merry-go-round is
with updating DNS (or anything else that has long
term name/address bindings). Simply put, DNS is
not a real time database and anything that wants
to push it in that direction is pretty well
doomed, at least in my opinion.

I'm not saying that we should give up here -- Dave
Oran and I have gone back and forth many times
about this -- we just need to go into this with
our eyes wide open; there's definitely no free
lunch in these parts.

	      Mike

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 06 Apr 2001 16:02:55 -0700

> doomed, at least in my opinion.

I surely would not consider mere DNS updates as a solution to the renumbering
issue

I have discussed this with people but don't know how this is received.

First we must differentiate between

    home-domain renumbering
     visited-domain renumbering or what I call island renumbering. This is the
case for MRs

In the home domain renumbering my solution would be to enable some peristent state
for dual prefix so that when an MN is away from home, its old prefix would sustain
for sometime (till it gets back or till it become reasonably stationary since we
wouldn not like to interfere with the handoff process. I assumed that renumbering
here does not happen on a daily basis.

The above is mainly to sustain interception of packets destined to the home addr
of the MN in the critical periods before the new home prefix could be conveyed
back to the MN at a suitable timing.

This need probably be coupled with an explicit renumbering notification back to
the MN informing it that the prefix is not what it used to be...however it is
important (in my thinking) not to enforce renumbering at a time that it may be
difficult for the MN (harsh fading conditions for instance). The notification
could carry the prefix as perceived by the HA.

The MN before or with the next BU should inform the HA about its current Home
address that ideally should be the a renumbered one. If the MN could not do that
then it MUST be expected to do that within the next 3 BUs or within a lifetime
that the persistent state would indeed persist. Beyond that it is the
responsibility of the MN (as with everything in life) to comply with the protocol
and stay in touch with home.

In the second case, "island renumbering" my perception is that the MN behind an MR
should not have to worry about renumbering on its own. It should be the MR that
would need to update its home prefix according to the above suggestion. If the
above was in effect AND any subnets underneath it had the same prefix then they
should all comply within some amount of time...

Here, for fixed nodes we could have the case of aggregate persistence in
intercepting packets for the fixed hosts underneath the MR.

Of course if the MNs underneath the MR happened to be visiting themselves then it
MUST not be their home addr that must get renumbered but the CoA.

So to sum up for island renumbering

both apparent and actual MNs are renumbering their CoA (i.e. another BU coming up)

for home domain renumbering and movement of the MR

apparent MNs (ie fixed hosts moving with the MR) are renumbering _twice_
    once their home addr (that is new home prefix)  (a BU coming out for the
update of the B-Cache)
    once their LCoA (that is new visited-domain prefix to comply with route
aggregation of the domain)   (another BU coming out....)

(actual MNs  (i.e. mobile hosts that visited the home net of the MR )

  need have only their LCoA renumbered. That means 2 BU in that visiting domain.
One for the initial acquisition of the LCoA and one for the new one due to visited
domain renumbering.

> our eyes wide open; there's definitely no free

I don't think that anybody can claim that there is such thing as free lunch since
the movement of the router and potential home renumbering are pretty major
tasks...in terms of routing state validity...

Theo

UCL / Mobile Systems

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 06 Apr 2001 16:25:49 -0700

Correction...

"....that there is _NOT_ such thing as free lunch..."

Theo

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 06 Apr 2001 10:48:31 -0700

Thierry,

Theo

UCL/ Mobile Systems

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

>   Having looked in detail the issue of mobile routers in HMIP
[...]
> inside, what would happen is that the interface attaching to the world

I fully agree.

> prefix aggregation scheme of IPv6 for that domain.

Sure.

> IPv6 for network renumbering per domain.

I fear that you go slightly too fast here. Before we move on, if we
discuss further along this line, the MR needs a topologically correct
prefix for the mobile network it is serving. I guess we both agree on
that. Since the COA for the upper interface of the MR belongs to P1 (in
accordance to Thierry's earlier figure) and P1 has prefix length
(usually /64), MR needs a new prefix to use for the mobile network.

This requires prefix delegation, e.g.
draft-haberman-ipngwg-auto-prefix-00.txt.

In this way, MR can get all the prefixes it needs for the mobile
networks it is serving. Next it needs to run a routing protocol between
itself and the delegating router so that packets can reach the nodes
behind the MR, this is also mentioned in the draft above.

Hopefully, if the MR moves within one domain for a while, and moves
between ARs that all belong to the same aggregated prefix (NLA or
whatever), it could keep on using the same delegated prefix(es) for the
entire stay in this domain. This assumes that the domain runs some
internal routing protocol. Whenever the MR moves to a new AR, it will
keep the prefixes it got earlier, but it will propagate routing updates
for the delegated prefixes to all routers within the domain. This will
not be significantly heavier on the internal routing since there is no
or little aggregation within one domain, and if there is, punching holes
in routing tables like this is no big deal as long as the number of
prefixes used in the domain isn't huge.

Ok, now the MR can go on and initiate renumbering of the mobile networks
it serves.

> rely on timeouts and intervals here the handoff is not that fast...

I'm afraid it will be trickier to move seamless for every new feature we
want to add to Mobile IP.

> to shrink the routing table, but we could allow for a temporal

Please see my comments above. Mobility is statistically quite local, so
I guess it's fair to assume that the MR probably stays within the domain
next time it moves.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 07 Apr 2001 17:31:07 +0200

[...]

I fully agree.

Sure.

/Mattias

---

From: James Kempf <[email-masked]>
Date: Sat, 07 Apr 2001 10:08:42 +0900

>addr). Ugly but I think it would work. This would cause triangular routing

Although I am probably at risk of getting lynched for even mentioning this,
having the mobile router act as a NAT might work.

                 jak

---

From: Michael Thomas <[email-masked]>
Date: Tue, 10 Apr 2001 15:57:57 -0700 (PDT)

Thierry,

I think we might be talking past each other. What
I was talking about is a mobile node (not a
stationary host) behind a mobile router. If they
are both off their home network, each in turn
would need to perform route optimization.

I think I've convinced myself that may be a
general problem with a naive approach. Consider a
a mobile node behind a mobile router, both away
from their home subnet. They have home agents HAr
and HAn respectively. Also, there is AR1 and AR2
which MR attaches to. The initial flow is:

CN->HAr->AR1->MR->HAn->MN
              |        |
<---BU--------+        |
                       |
<--------BU------------+

That is, each time a packet arrives on its home
agent tunnel interface, that node sends a BU.
We get route optimization because it sends it
Co(MR) and then Co(MN) which is the least 
cost route. Thus each IP packet to MN from 
CN is (initially):

DST(CoA(AR1.x)):RH(CoA(MR.y)):RH(CoA(HAn.z))

When the MR moves, after it's sent its
BU to the CN, the flow is:

CN->AR2->MR->MN

The CN->MN packets now look like:

DST(CoA(AR2.c)):RH(CoA(MR.y)):RH(CoA(HAn.z))

The potential problem lies in the ordering of
the routing headers. If instead -- for whatever
reason -- the CN formed a packet like:

DST(CoA(MR.y)):RH(CoA(AR2.c))):RH(CoA(HAn.z))

it would then take the route:

CN->HAr->AR2->MR->MN
              |
<----BU-------+

which would seemingly either get into a loop, or
non-optimal routing. What I don't see is how CN
can sort this all out. How, for example, does it
know that MR is topologically closer which is the
key to getting the routing header stack right?!?

	       Mike

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 11 Apr 2001 11:04:22 +0200

Hi all, Michael,

>  > can tell them where is the MR.

To clarify: I meant "the solution to the problem you are stating depends
whether we use my solution to support mobile networks, or HMIP", then
any discussion is pure theory...

> would need to perform route optimization.

Don't take me wrong, I understood what you said.  I use to call a cat a
cat:

o A MN is a node which is changing it's point of attachment, no matter
what is the point of attachment (a fixed router or a mobile router).    

o A MR is a router which is changing its point of attachment.  

o A Stationary Node (SN) is a node which is not changing its point of
attachment.    If a MR and all its attached nodes is moving, its
attached SNs are still attached to it and I don't call them "MNs". 

> key to getting the routing header stack right?!?

The problem you are speaking about is clear to me and to anyone who
would think about it for a little while, and it is not yet documented in
my draft (i.e. sending the mobile_network_prefix to HA and CNs) since I
over-simplified it to get a clear picture of (some of) the potential
problems.  It currently only address the case where there are no MNs
behind the MR.  It could also address MN behind the MR, but there are
additional problems, amongst them the "Routing Header Ordering".

Anyway, you can basically perform route optimization between CN and
MN_behind_the_MR with my proposal, but the CN operation needs to be
modified in order to know how to fill the Routing Header with 2 COAs:
one for the MR, and one for the MN.  This is tricky, but a longest
prefix match would be enough to decide which COA needs to be included
first.   The problem I can see is ratter the cost of signalling has both
the MR and the MN need to advertise their own COA.

I don't want to enter into details right now because I need to solve
other aspects (mainly authorization) before I design the overall
solution.   Anyway, I will document my draft before next IETF meeting
and address some of the issues I have left behind.    

I think we need to agree that the issues of Mobile Routers and Networks
is sufficiently important to be addressed by the MIP WG.   I think
everyone agree that there are problems to be solved. At least the past
discussions has shown that quite a few people are trying to tackle the
problems and some have voted for it to be included in the WG charter. 

Cheers,
Thierry.

http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt
--
* mailto:[email-masked]  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/