headers
marcelo bagnulo | 2 Jan 00:23
Picon

RE: Updated HIP mobility & multi-homing draft

Hi Pekka,

If i understand it correctly, the draft essentially specifies the required
mecnahins and extensions to the HIP protocol to safely modify the set of
addresses that can be used by two communicating hosts to reach each other.
While this is a fundamental part of a mechanism to preserve established
communications in multi-homed and mobile environments, it is not by itselt
enough to provide multi-homing nor mobility support.
Additional mechanisms and tools are required to preserve established
communications both in mobile and multihomed environments, including
mechanisms to deal with ingress filtering (multi-homing and mobility),
detect movment (mobility), detect outages (multi-homing), locator selection
for initial contact, etc.

It would be interesting to try to understand how HIP (and the extensions
presented in this draft ) can deal with all these issues, so it can provide
a complete solution to preserve established communications.
You mention that another draft is comming, perhaps are you planning to
inlcude all the rest of the issues in this next draft?

Thanks for the draft, regards, marcelo

> -----Mensaje original-----
> De: owner-multi6 <at> ops.ietf.org [mailto:owner-multi6 <at> ops.ietf.org]En
> nombre de Pekka Nikander
> Enviado el: lunes, 29 de diciembre de 2003 9:15
> Para: hipsec <at> honor.trusecure.com
> CC: multi6 <at> ops.ietf.org
> Asunto: Updated HIP mobility & multi-homing draft
>
(Continue reading)

Permalink | Reply | 10 comments |
headers
Jari Arkko | 2 Jan 12:35

Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft

Hi Marcelo,

Thanks for your comments. Some discussion inline:

> If i understand it correctly, the draft essentially specifies the required
> mecnahins and extensions to the HIP protocol to safely modify the set of
> addresses that can be used by two communicating hosts to reach each other.
> While this is a fundamental part of a mechanism to preserve established
> communications in multi-homed and mobile environments, it is not by itselt
> enough to provide multi-homing nor mobility support.

I agree its just a part of the whole solution.

> Additional mechanisms and tools are required to preserve established
> communications both in mobile and multihomed environments, including
> mechanisms to deal with ingress filtering (multi-homing and mobility),

I do not understand why we need anything special for ingress filtering.
Hosts should only use the addresses they have been given in the
particular interface. If you move around, you will use new addresses.

> detect movment (mobility),

This is definately an issue. We already realized this in Mobile IPv6.
Currently, the IETF is planning a new WG to address movement detection
issues, the DNA working group. My hope is that the results of that will
be generally applicable to HIP, MIPv6, as well as plain hosts with no
mobility support. I think we also want to avoid putting solutions for
this in the HIP documents themselves.
(Continue reading)

Permalink | Reply | 9 comments |
headers
marcelo bagnulo | 3 Jan 00:59
Picon

RE: [Hipsec] RE: Updated HIP mobility & multi-homing draft

> > Additional mechanisms and tools are required to preserve established
> > communications both in mobile and multihomed environments, including
> > mechanisms to deal with ingress filtering (multi-homing and mobility),
>
> I do not understand why we need anything special for ingress filtering.
> Hosts should only use the addresses they have been given in the
> particular interface. If you move around, you will use new addresses.

In the multihoming case, one interface has multiple global addresses
assigned, and the host must select which one to include in the packet as
source address
Once that the packet leaves the host, it is up to the intrasite routing
system to carry the packet to one of the exit isps.
The problem appears when the exit isp selected by the routing system and the
source address selected by the host don't match (ingress filtering discards
the packet)

So a mechanism is needed to coordinate the exit isp and the source address
Several options are possible, like source  routing in multiple flavors,
source address rewriting, letting the routing system inform the host which
address to use with a given destination address.

I guess that it would be interesting to understand how compatible are those
mechanisms with the HIP solution... for instance it would be possible to
rewrite the source address of the HIP packets?

>
> > detect movment (mobility),
>
> This is definately an issue. We already realized this in Mobile IPv6.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jari Arkko | 3 Jan 10:22

Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft

marcelo bagnulo wrote:
>>>Additional mechanisms and tools are required to preserve established
>>>communications both in mobile and multihomed environments, including
>>>mechanisms to deal with ingress filtering (multi-homing and mobility),
>>
>>I do not understand why we need anything special for ingress filtering.
>>Hosts should only use the addresses they have been given in the
>>particular interface. If you move around, you will use new addresses.
>
>
> In the multihoming case, one interface has multiple global addresses
> assigned, and the host must select which one to include in the packet as
> source address
> Once that the packet leaves the host, it is up to the intrasite routing
> system to carry the packet to one of the exit isps.
> The problem appears when the exit isp selected by the routing system and the
> source address selected by the host don't match (ingress filtering discards
> the packet)
>
> So a mechanism is needed to coordinate the exit isp and the source address
> Several options are possible, like source  routing in multiple flavors,
> source address rewriting, letting the routing system inform the host which
> address to use with a given destination address.

Ah yes. This is in fact a discussion we had also in the SEND WG during last
couple of days. At least some people that I talk to think that this is
a general issue for the IPv6 and multi6 WGs to fix their protocols -- the
issue appears even when you do not employ e.g. HIP or SEND or MOBIKE.

>>HIP does introduce a few additional twists to movement detection,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Masataka Ohta | 3 Jan 12:41
Picon

Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft

Jari Arkko;

> marcelo bagnulo wrote:
> 
>>>> Additional mechanisms and tools are required to preserve established
>>>> communications both in mobile and multihomed environments, including
>>>> mechanisms to deal with ingress filtering (multi-homing and mobility),

> Ah yes. This is in fact a discussion we had also in the SEND WG during last
> couple of days. At least some people that I talk to think that this is
> a general issue for the IPv6 and multi6 WGs to fix their protocols -- the
> issue appears even when you do not employ e.g. HIP or SEND or MOBIKE.

That's why proposals should be intended to be complete.

At this stage, incomplete solutions are totally useless for
productive discussions.

However, the solutions are not required to solve mobility specific
ingress filtering issues, unless they actively disturb exsiting
capability of ingress filtering with some existing mobility
protocols.

> Right. No, we do not have an answer to these questions yet. One
> potential answer is that we can simply track the usage of the SAs
> that HIP has created. Details to be worked out, however.

You can work forever to fix the details, only after which, make
public proposals.
(Continue reading)

Permalink | Reply | 2 comments |
headers
marcelo bagnulo | 3 Jan 16:31
Picon

RE: [Hipsec] RE: Updated HIP mobility & multi-homing draft

> That's why proposals should be intended to be complete.
> 
> At this stage, incomplete solutions are totally useless for
> productive discussions.

FWIW, IMHO this HIP draft is interesting and useful

Regards, marcelo
Permalink | Reply | 1 comment |
headers
marcelo bagnulo | 3 Jan 16:31
Picon

RE: [Hipsec] RE: Updated HIP mobility & multi-homing draft

> Ah yes. This is in fact a discussion we had also in the SEND WG
> during last
> couple of days. At least some people that I talk to think that this is
> a general issue for the IPv6 and multi6 WGs to fix their protocols -- the
> issue appears even when you do not employ e.g. HIP or SEND or MOBIKE.

I agree this is a common problem of many of the multihoming solution, and it
should be addressed by each of the particualr solutions.
Since we are considering a multihoming solution based in HIP, we should try
to understand how a HIP solution can deal with this and how it can interact
with possible solutions for this problem.

...

>
> It does. I'm just trying to understand the best way to address this "big
> picture" problem. Actually, maybe you or someone else can help here, as I
> have not been involved in multi6 work.

I can try to help with this.

> Is there a problem statement or an
> explanation of functionality that would cover all these aspects?

RFC 3582 contains the goals for multihoming
Elliot's draft contain a good amount of interesting questions that we should
try to answer when designing a multi6 solution
(draft-lear-multi6-things-to-think-about-00.txt)
You can also read D. Crocker's draft for an analysis of the big picture
draft-crocker-mast-analysis-01.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Masataka Ohta | 4 Jan 03:23
Picon

Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft

marcelo bagnulo;

>>That's why proposals should be intended to be complete.
>>
>>At this stage, incomplete solutions are totally useless for
>>productive discussions.
> 
> 
> FWIW, IMHO this HIP draft is interesting and useful

With your context of:

> Since we are considering a multihoming solution based in HIP, 

it should be.

But, I am not interested in considering a multihoming solution based
on HIP that it is neither interesting nor useful.

						Masataka Ohta
Permalink | Reply | 0 comments |
headers
marcelo bagnulo | 4 Jan 20:17
Picon

RE: LIN6 i-d for multihoming and mobility support

Hi Fumio,

Some comments about this draft.

My main concern about this proposal is about the Mapping Agent

The mapping agent becomes a critical part since it is required to establish
the communication, so in a multi-homed environment, where do you place it?
do you place it in the multihomed site or in the isps? what happens if the
path to the MA is down? i guess that since one of the goals of multihoming
is the provision of a more resilient network, the inclusion of an additional
critical device must be very well justified and the potential failures of
such device must be studied in depth

Besides, the usage of a mapping agent introduces additional latency and
traffic since, if i understood it correctly, several new round trips are
required i.e. a query to the MA from the initiator and a reverse DNS query
and a direct DNS query and a MA query from the receiver is also required.
These are a lot of additional packets and time required to initiate the
communication

Finally, i really don't understand why the mapping agent is needed in the
multi-homed environment. I mean, i do understand that the MA is needed for
mobility, but i think it is not needed for multihoming. In the noid
proposal, the mechanism is similar (i think) but only the dns is used. This
is good because you don't add an additional critical device and you reduce
the packet exchanges (you don't have to query the MA)

Additionally, there are multiple issues that are not addressed in the draft
and that IMHO it would be important to understand how they can be addressed
(Continue reading)

Permalink | Reply | 3 comments |
headers
Masataka Ohta | 4 Jan 23:04
Picon

Re: LIN6 i-d for multihoming and mobility support

marcelo bagnulo;

> Finally, i really don't understand why the mapping agent is needed in the
> multi-homed environment. I mean, i do understand that the MA is needed for
> mobility, but i think it is not needed for multihoming.

Agreed, which is why I am preparing my own proposal based on LIN6
based implementation and deployment experience.

						Masataka Ohta
Permalink | Reply | 0 comments |

Gmane