Subject: RE: [mobile-ip] artificial local distinctions

From: [email-masked]
Date: Sun, 23 Mar 2003 20:51:27 -0800

I don't think that anybody is against to "align FMIP better with existing ND signaling and to make the security more straightforward". This is very good intention. However, the architectural concept of local mobility to achieve this remains unclear. I have some very basic questions about this. 

How many hops must local mobility signaling travel before it becomes global? 

After the latest events in the IPv6 wg (i.e. deprecation of site local addressing), address scoping is not helpful to make a distinction between global and local signaling. All addressing is either link local or global. If the movement is within a link, I think that it should be transparent to the IP layer, but if it is between two interfaces then it is visible to IP layer because the interface IP address (default router changed). 

Now when a node leaves its home link (home subnet) and moves to a neighboring subnet, what kind of signaling needs to be used global or local? What would be the scope of addressing? Link local or global, or something else. Or is it a question of the network domain, or security domain? 

These are very basic questions, and so far everything we have seen seems to indicate that we  could do pretty well with only one kind of addressing and with one kind of signaling messages that inherits from base MIPv6 and works with ND and its likely extensions if  you wish.

Regards Hannu 

-----Original Message-----
From: ext Michael Thomas [mailto:[email-masked]]
Sent: Sunday, March 23, 2003 12:21 PM
To: James Kempf
Cc: Michael Thomas; [email-masked]
Subject: [mobile-ip] artificial local distinctions

James Kempf writes:
 > Michael,
 > 
 > One argument for separating local and global mobility is to provide more
 > modularity in the design. 

   In isolation, modularity buys nothing. Your claim is
   that thinking of this as two separate spaces buys us
   something. I don't see it.

 > Though it seems hard to imagine now, it might be
 > possible that at some point MIP is replaced by something else. 

   Um, so? This is a non-sequitur.

 > It would be good
 > if the overall IP mobility protocol suite could have enough flexibility to avoid
 > having to change the local signaling because the global mobility management
 > changed. 

   Why? And what prevents anybody from doing that as things
   stand now?

   There is a distinct downside of speciation. There needs
   to be compelling reasons why one would want to do that.
   How designers expect people will deploy things
   is usually not a very good reason as good
   protocols often get used in unexpected ways.

	     Mike

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 24 Mar 2003 12:58:56 +0200

[email-masked] wrote:
> I don't think that anybody is against to "align FMIP better with
> existing ND signaling and to make the security more straightforward".
> This is very good intention. However, the architectural concept of
> local mobility to achieve this remains unclear. I have some very
> basic questions about this.
> 
...
> These are very basic questions, and so far everything we have seen
> seems to indicate that we  could do pretty well with only one kind of
> addressing and with one kind of signaling messages that inherits from
> base MIPv6 and works with ND and its likely extensions if  you wish.

I don't think that the real technical distinction is so
much how far the mobile node moves, but with home it
communicates.  In most cases both "local" and "global"
signalling would be used.

When the MN informs its HA or a CN about mobility, that
is basically "global" mobility.  OTOH, when the MN
signals with its RAs locally, that is "local" mobility.

As I wrote at the mipcharter list, IMHO regional
mobility (i.e. HMIP) is a border case which can be
implemented with either kind of signalling.

One reason why I am promoting this distinction is that
I do not personally believe very much in MIPv6.  Instead,
I believe that it will be eventually replaced with something
better, something based on the identifier/locator separation.
(What "eventually" means in the context above is a good
question, and I don't have any good answers to that.)
 From that point it would be silly to use MIPv6 signalling
in "local" mobility.

--Pekka Nikander

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 24 Mar 2003 08:26:19 -0800

Hello Pekka,

I have one or two comments inline...

> signals with its RAs locally, that is "local" mobility.

By this characterization, FMIP is "local" mobility, right?
Anyway, that's how I think about it.

> From that point it would be silly to use MIPv6 signalling

By this characterization, such discussion is strictly
out of scope for a(ny) working group concerned with
Mobile IPv6.  I think it's analogous to IPsuper-ng+++!!+++
proponents trying to insert their agenda into the IPv6
working group discussion and mailing list.  Sometimes
they believe in it so strongly that they have to be
banned administratively from carrying out their agenda.

However, I might suggest that you are looking at things
in reverse order.  Perhaps we should aspire to a future
for which the IP address is not the common/universal identifier
for a device.  Perhaps we should aspire to a future for which
device identifiers aren't even interesting.  Along the way,
we will learn a lot about mobility by using Mobile IPv6 and
associated protocols which do use the IP address as an
identifier, and provide a mapping between the identifier
and the locator.

Since, presumably, the identifier could be anything that we
find convenient, then we could presumably work with the case
in which the identifier is (for convenience) a layer-3 address.

It seems to me that, before we can change to something else
for the identifier, we ought to change TCP so that it can use
that something else to anchor its protocol state.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 Mar 2003 09:39:52 -0800 (PST)

> How many hops must local mobility signaling travel before it

Well, that's pretty much my point. Trying to nail
this kind of question down seems entirely beside
the point for this working group because it's a
network engineering kind of question, not a
what-should-the-protocol-do question. The reason
I'm suspicious of drawing these kinds of
distinctions is precisely because those kinds of
fruitless discussions are encouraged.

	      Mike

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Mar 2003 20:42:05 +0100

> How many hops must local mobility signaling travel before it 

Hi Hannu,

This is a very good question that doesn't have an answer neither at
IETF nor at IRTF, neither in any other open research (from what I've
seen).

I formulated it to rr-mm RG like this: what's the threshold size of
the local mobility domain starting at which a pure-routing-based
approach becomes infeasible due to growth of rt sizes, threshold at
which Mobile IP becomes a MUST.

It is indeed a question that looks to me purely IRTF, but I do think
there is a threshold; just a humble note, and not inducing any
personal agenda item here.

Alex

-- 
Message Classification: GBU

---

From: Alper Yegin <[email-masked]>
Date: Mon, 24 Mar 2003 11:30:40 -0800

Hi Pekka,

> I do not personally believe very much in MIPv6.

I agree that we can break the complete mobility management into
local mobility management and global mobility management for various
reasons like optimizations, location privacy, etc. If we can do a clear and
modular job here (as we are already doing with MIP, HMIP, FMIP), any
part of it can be MIP-based or something else today and in the future.
So, I don't think this stucture dictates any particular choice for any of
the components.

alper

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 24 Mar 2003 21:58:00 +0200

Hello Charlie,

> Anyway, that's how I think about it.

That is more or less how I think about it, too.  But I
don't restrict "local" mobility solely to FMIP; any
mobility signalling that *cannot* (or should not) across
the Internet, i.e. is naturally *restricted* to happen
only locally, is local mobility.  (Please let us not go
to fine nits here.  This is a classification, for the
benefit of the discussion, and there are border line
cases that one can decide one way or another.)

...
> Mobile IPv6. 

I can't but agree with you.  I am sorry that I posted
my previous message to the mobileip mailing list.  I have
mostly been posting on the mipcharter mailing list,
where opinions such as that are more appropriate.
However, based on the earlier discussion on the thread,
I wanted to clarify my position wrt. the draft James and
I wrote.

More sincerely, why do you think that I have used that many
cycles in being a member of the MIPv6 RO DT and later writing 
draft-nikander-mobileip-v6-ro-sec-00.txt
(to appear shortly, available at http://www.tml.hut.fi/~pnr/MIP/)
even if I don't like Mobile IPv6?  Because I think that
MIPv6 is *important* even though I don't like it.

> identifier, and provide a mapping between the identifier

I agree that we most probably will learn lots from Mobile IPv6,
independent on whether it is a huge success or a lesser one.
Even if I don't like it for architectural reasons, it is here
to stay, and I believe that it will be deployed.  I also
believe that it will be the first time IP mobility gets deployed
big time, since Mobile IPv4 does not seem to get that widely
accepted.  Hence, it will be an important experience to learn
from.  And most probably it will be useful, too :-).

> in which the identifier is (for convenience) a layer-3 address.

Well, this is probably out-of-topic at mobileip mailing list,
but I don't quite think that the identifier could be "anything".
If you want to discuss that more, we can move this discussion
off from the mailing list.

> that something else to anchor its protocol state.

Right.  Or change the architecture underneath TCP, which
amounts the same thing.  But that's again off-topic.

--Pekka Nikander

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 24 Mar 2003 12:15:11 -0800

Hello Pekka,

Seems that we are in pretty good agreement.
Just to clarify:

Pekka Nikander wrote:

> only locally, is local mobility.

The important point is to get performance by doing some
local signaling.  FMIP does so, and there may be other
approaches.  But it's more of a practical matter, than
a *restriction*.  If someone wanted to run FMIP between
two far-distant access points, then it should be possible
at least to the extent of not crashing the systems involved.
One might ask how in the devil the mobile node moved so
fast, but that's not a "best effort" question :-)
The distance involved would probably negate any performance
advantage achievable from running the protocol.

Since no *restriction* is required, then the classification
by which such a restriction might be enforced could also
be superfluous, except insofar as a way to understand the
performance effects.  This is not a protocol mandate, but
a description of reality.

> MIPv6 is *important* even though I don't like it.

No one doubts that you have made important contributions, least
of all your BAKE co-author!  I hope I didn't imply otherwise.
However, I have sensed that various other approaches which
lie outside the network-layer have been used to make hints
that Mobile IPv6 isn't worthwhile.  Everyone is entitled to
their opinions on this, but maybe those opinions are not the
most constructive ones within the working group that is trying
to make Mobile IPv6 itself into a better solution.

None of which should be construed to deprecate your contribution!

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 Mar 2003 14:03:36 -0800 (PST)

> cases that one can decide one way or another.)

OK, I'll bite. What mobility traffic cannot or
should not go across the Internet and why? What
bad things happen if they do? There's a vast
difference between "doesn't make sense" and
"causes harm."  You seem to arguing that there
exists instances of the latter.

		 Mike

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 25 Mar 2003 10:03:23 +0200

> exists instances of the latter.

It looks like I argued my case badly above.  I'll
spend more cycles on revising our draft, but a brief
answer.

IP mobility involves changing IP addresses.  If such
a change is visible to all of the internet, the address
*must* be signalled across the Internet, eventually.
If such a change is *not* visible to all of the Internet,
the change *cannot* (or at least should not) be signalled
access the Internet, since it does not make any sense
at the other end.  Thus, any signalling that considers
local address changes is naturally restricted to the
some topologically restricted area, i.e., to some locality.
Hence the term "local" in the first place.

But again, the distinction between local/global mobility
is an attempt to clarify thinking.  If people don't buy
it and think that it only makes things muddier, then fine.
Perhaps the thinking is flawed.  (I don't believe it is
flawed, but I always try to keep my mind open for the
case were I am wrong or where I have muddier thinking than
some other people.)

--Pekka Nikander

---

From: Michael Thomas <[email-masked]>
Date: Tue, 25 Mar 2003 05:24:31 -0800 (PST)

> *must* be signalled across the Internet, eventually.

Well, more precisely, it's visible (FSVO visible) along
the paths that packets take. Which may or may not have
various threats. I assume that you're not making the
assumption that the "local" domain is necessarily benign.

 > Hence the term "local" in the first place.

I'm not groking this well because it seems almost
tautological. You are going to have threats -- and
defenses thereof -- as far as the signaling
traverses.  If the threats are in the local loop
or thereabouts, thinking about localization
doesn't really help you because those threats
can't be factored out. In fact, it probably is the 
local loop kinds of threats over the air that are
the most troublesome, so I just don't see what we
gain by trying to segment the problem.

 > case were I am wrong or where I have muddier thinking than

Well, to be fair, it didn't occur to me until
relatively recently that my own narrow thinking
about localization wasn't helpful as the
functionality of tunneling with the ability to
change the endpoint addresses is useful in a
number of cases, and that it was the general
functionality rather than their currently intended
use that was the important property. Note that I'm
not saying that everything need be completely
applicable to any arbitrary topological distance;
merely that we not specifically design artificial
restrictions in where they aren't strictly
needed. The world is full of surprises.

	Mike