Subject: RE: Consensus on identifier/locator split?

From: "Christian Huitema" <[email-masked]>
Date: Thu, 7 Aug 2003 09:17:05 -0700

> Actually, if you reuse MIPv6 mechanisms to handle the "existing TCP
> connections" case, you might be able to get both levels of functionality
> without any changes.

That is certainly a reasonable option. In fact, back in 1995, the reason we did not pursue the "TCP optimization" path was that the "binding update" mechanism of MIPv6 was thought to provide equivalent functionality. MIPv6 also provides a reasonable "opt-in" mechanism: hosts implement the correspondent node facility if they want to enable TCP connection to survive a "re-homing event" at their peers; applications can opt for binding to a "long duration" source address if they want to use long duration connections, and to the "short term best" if they don't, or if they have another way to deal with mobility.

Which is to say, I would be much more confortable examining a specific proposition, such as "use of MIPv6 to survive re-homing events", rather than a generic proposition of "let's split".

-- Christian Huitema

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Aug 2003 10:24:15 +0859 ()

Christian;

> Which is to say, I would be much more confortable examining a specific proposition, such as "use of MIPv6 to survive re-homing events", rather than a generic proposition of "let's split".

At Vienna, I explained three reasons on why MIPv6 is hopeless.

That is,

	its handover is too slow to be useful for any realistic
	application

	it is server (home agent) based

	it reduces MTU to violate the IPv6 specification

The second one is multi6 specific, while the first and the third ones
are generic. But, I think any of the reason is fatal.

Now, you have a chance for counter argument.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 12 Aug 2003 20:08:11 -0300

Hi Masataka,

I concur that MIPv6 as is cannot be used to provide multi-homing
support.
I think that there are parts of MIPv6 that may be recycled into a
multi-homing solution.
That is:

The basic protocol, i.e. the packet formats required to provide
multi-homing support are similar to those required to provide mobility
support (BU, BA), so the protocol itself can be reused (i am not talking
about node behaviors or even roles defined by MIPv6)

Another benefit that could be achieved with a MIPv6 based multi-homing
solution would be to use the CN functionality with the minimum amount of
changes, reducing the deployment effort (since these capabilities are
already there)

I agree with you that the mobile node behavior (in particular the
timers) are not suitable to be used to provide multi-homing support.
Moreover, as you mention, the role of the HA is not appropriate for
multi-homing support.
But at this point it must be noted that the important changes required
are limited to the behavior of the nodes within the multi-homed site
i.e. the nodes that are actually benefiting from the solution, So in
this case it seems reasonable to impose that these nodes have to be
modified.

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] 
> [mailto:[email-masked]] En nombre de Masataka Ohta
> Enviado el: lunes, 11 de agosto de 2003 22:25
> Para: Christian Huitema
> CC: J. Noel Chiappa; [email-masked]
> Asunto: MIPv6 hopeless
> 
> 
> Christian;
> 
> > Which is to say, I would be much more confortable examining 
> a specific 
> > proposition, such as "use of MIPv6 to survive re-homing events", 
> > rather than a generic proposition of "let's split".
> 
> The second one is multi6 specific, while the first and the 
> third ones are generic. But, I think any of the reason is fatal.
>

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 14 Aug 2003 10:34:33 +0859 ()

Marcelo;

> Moreover, as you mention, the role of the HA is not appropriate for

Then, which part of MIPv6 basic protocol,

> about node behaviors or even roles defined by MIPv6)

are you saying, can be reused?

Ones between MN and CN? How is the security, then?

> timers) are not suitable to be used to provide multi-homing support.

It should be noted that the behavior is not suitable to be used
to provide mobility (because it is not suitable for any application),
either, which is one of a reason among many why I say MIPv6 hopeless.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 14 Aug 2003 12:06:01 -0300

> > support (BU, BA), so the protocol itself can be reused (i am not 
> > talking about node behaviors or even roles defined by MIPv6)
> 

Yes.

I mean, suppose you (host1) are in a multi-homed site and you have
multiple addresses. You are currently using one to communicate with
host2.
Suddenly a outage occurs along the path that you are using to
communicate. What you need is a signaling mechanism that allows you to:
1- Inform host2 that an alternative address is to be used to continue
with the communication. This is what BU message is for in mobility, so
it seems reasonable that it is suitable for this task)
2- A mechanism to enable the end of the communication to identify
packets with alternative addresses as belonging to the initial
communication (this is what the Type 2 Routing header and Home address
option is used for in mobility, so again they are good candidates)

Clearly, you need to build alternative triggering mechanism. I mean, in
mobility, BUs are triggered by movement detection mechanism. In this
case you are not moving so this is not useful. What is needed is a
failure detection mechanism that is the one that will trigger the BUs.
This mechanism is not provided by MIP. Important benefits are achieved
if this mechanism does not impose modification in host2 

> Ones between MN and CN? How is the security, then?

This is the difficult part, i guess.

MIP security is based in the RR procedure, which implies connectivity
through both paths. However in the multi-homing scenario, you want to
use an alternative path because the former path is no longer available,
so you cannot perform the RR procedure once that the outage has
occurred. However, there is another relevant difference between
multi-homing and mobility that is that the multihomed host knows all the
available addresses in advance. So, it is possible to perform the RR
procedure authorizing future bindings with all the alternative addresses
available, so that in case of an outage, there is BU authorization data
available for all the alternative addresses. 
The problem with this is that the authorization data has a limited
lifetime, so you need to acquire valid authorization data periodically.
This may not be problem, since you could use the RR procedure packet
exchange as a failure detection mechanism if the frequency is increased.
Another problem is that the binding information in the CN has a limited
lifetime also in order to prevent time shifting attacks (yes, time
shifting attacks do exist and no, i am not inventing new terminology
here)
IMHO this issue cannot be solved without introducing some (minor)
changes in host2 behavior.
The problem here is that time shifting attacks prevention is based in
probing that the communication end is still there. However in the
multi-homing case, the other node is not there (i mean, it is there but
there is no path to it), so you need to differentiate the case of a time
shifting attack where the other end is not there and the case where the
host is still there but there is no path to it. The tool that can be use
to cope with this is ICMP messaging, since when there is no route to the
hosts, an ICMP message is generated. This way, the communication parties
can tell whether they are victims of a time shifting attack (there is an
available route, but the host is no longer there) or there is no route
to the host.

Regards, marcelo 

> It should be noted that the behavior is not suitable to be 
> used to provide mobility (because it is not suitable for any 
> application), either, which is one of a reason among many why 
> I say MIPv6 hopeless.
> 
> 							Masataka Ohta
>

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2003 06:24:33 +0859 ()

Marcelo;

As I presented at Vienna, there is certain relationship between
mobility and multihoming, because both handles multiple
addresses, but the relationship is less than expected.

> it seems reasonable that it is suitable for this task)

And security is the issue.

> option is used for in mobility, so again they are good candidates)

Routing header is a waste of bytes and a possible cause of
MTU reduction problem.

> if this mechanism does not impose modification in host2 

A properly designed mobility protocol should support multiple
home agents at multiple locations.

But, the feature is missing in MIPv6. Note that an MIPv6 feature
of having multiple home agents at a single subnet is nothing more
than a useless complication.

So, there is nothing to be reused and we should define a packet
format to support site multihoming, which can be reused to
support multiple home agents at multiple subnets.

> MIP security is based in the RR procedure,

MIP security is based on shared secret shared between mobile hosts
and home agents.

							Masataka Ohta

---

From: Tim Shepard <[email-masked]>
Date: Wed, 20 Aug 2003 21:53:07 -0400

> home agents at multiple locations.

And I would also like to see support for the homeless mobile node.
So "multiple home agents" should range from zero to many.

			-Tim Shepard

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2003 11:25:19 +0859 ()

Tim Shepard;

> So "multiple home agents" should range from zero to many.

I'm afraid that the analogy between multihoming and mobility
works here and that the homeless mobile node will be as useful
as a zero homed sites in which hosts have zero prefixes.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 21 Aug 2003 09:19:51 +0300

> as a zero homed sites in which hosts have zero prefixes.

Which, IMHO, are both fairly useful in certain situations :-)

--Pekka NIkander

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 21 Aug 2003 10:20:07 -0300

> De: Masataka Ohta [mailto:[email-masked]] 
> Enviado el: miércoles, 20 de agosto de 2003 18:26
> Para: marcelo bagnulo
> CC: 'Christian Huitema'; 'J. Noel Chiappa'; [email-masked]
> Asunto: Re: MIPv6 hopeless
> 
> 
> Marcelo;
> 
> As I presented at Vienna, there is certain relationship 
> between mobility and multihoming, because both handles 
> multiple addresses, but the relationship is less than expected.
> 

agree

> Routing header is a waste of bytes and a possible cause of

May agree with this also. However, reusing existing aproved protocols
also has benefits

> > Clearly, you need to build alternative triggering 
> mechanism. I mean, 
> > in mobility, BUs are triggered by movement detection mechanism. In 
> > this case you are not moving so this is not useful. What is 
> needed is 
> > a failure detection mechanism that is the one that will trigger the 
> > BUs. This mechanism is not provided by MIP. Important benefits are 
> > achieved if this mechanism does not impose modification in host2
> 

The aplication of MIP to multi-homing support that i am describing does
not use a home agent

> But, the feature is missing in MIPv6. Note that an MIPv6 
> feature of having multiple home agents at a single subnet is 
> nothing more than a useless complication.
> 
> So, there is nothing to be reused and we should define a 
> packet format to support site multihoming, which can be 
> reused to support multiple home agents at multiple subnets.
> 
> MIP security is based on shared secret shared between mobile 
> hosts and home agents.
> 

NO.
Read mipv6 specification and in particular read the description of
return routability procedure

Regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Aug 2003 04:14:32 +0859 ()

Marcelo;

> May agree with this also. However, reusing existing aproved protocols

If only the protocols were hopeful.

> The aplication of MIP to multi-homing support that i am describing does

A mobile host has a stable address(es) to be published by,
say, DNS.

Something taking care of the address(es) is the home agent.

That is, you are either not describing mobility (because address
changes as hosts move) or describing home agent aspect of mobility.

> return routability procedure

Read the draft and think.

There is no return packet, if you have no idea on where to send
a initial packet.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 22 Aug 2003 11:06:20 -0300

> > The aplication of MIP to multi-homing support that i am describing
> > does not use a home agent
> 
> A mobile host has a stable address(es) to be published by, say, DNS.
> 

and the mobile node when it is at the home network?

> 
> That is, you are either not describing mobility (because
> address changes as hosts move) or describing home agent 
> aspect of mobility.
> 

> There is no return packet, if you have no idea on where to
> send a initial packet.

So, where is the shared secret?

Regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Aug 3 18:09:35 JST

Marcelo;

> and the mobile node when it is at the home network?

Are you saying that the mobile node is always at the home network?

So?

> So, where is the shared secret?

Read the draft.

							Masataka Ohta