From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: "'TAO YUAN'" <alberty.2004@gmail.com>, "hipsec@ietf.org" <hipsec@ietf.org>
Date: Tue, 4 May 2010 20:08:04 -0700
Thread-Topic: [Hipsec] HIP host multihoming questions
Thread-Index: AcrrYK2l480IGtV5Roq2JJZdAFOZPwAnTgXQ
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE97160F2@XCH-NW-10V.nw.nos.boeing.com>
References: <z2o318ac2b81005040106x2de9c5b9n777c5d14b6577e6f@mail.gmail.com>
In-Reply-To: <z2o318ac2b81005040106x2de9c5b9n777c5d14b6577e6f@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Hipsec] HIP host multihoming questions
Precedence: list

> -----Original Message-----
> From: hipsec-bounces@ietf.org
> [mailto:hipsec-bounces@ietf.org] On Behalf Of TAO YUAN
> Sent: Tuesday, May 04, 2010 1:06 AM
> To: hipsec@ietf.org
> Subject: [Hipsec] HIP host multihoming questions
>
> Hi, all
>
> I have some questions about HIP host multihoming.
>
> Consider a scenario described below:
>
> Host A is a multihomed HIP host, which using address IP1 on iterface_1
> to communicate with host B. For fault-tolerant or maybe some other
> purposes, A decides to inform B about its another address IP2 on
> interface_2.
> According to rfc5206, it is a 3-way update process. After this, a new
> pair of SA is created between A and B. We assumed A needs to switch
> its communication with B from interface_1 to interface_2.This may
> caused by the breakdown of interface_1's connected link or upper
> applications' requirements for better performance. Host A initiates
> another 3-way update process, which aims at informing B to send
> packets to A's interface_2 instead of interface_1. If not doing this,
> B may still send packet to interface_1, since it always regards IP1 as
> the preferred address until receives A's notification. More
> explicitly, B won't send packet to interface_2 until it is aware of
> the disconnection of current link due to transport layer mechanism.
> The latency could be very large.
>
> Is this means for an interface switching, host A needs to initiate the
> 3-way update process twice? Host A uses the first one to create a new
> SA, and the second one to notify B about interface switching. And if
> so, why can't we let host A initiate only one update process after its
> interface switching to create a new SA and notify the preferred
> address, which just like the normal mobility event? It looks like more
> reasonable, and initiate update process twice is wasteful.

I believe that what you are suggesting would be appropriate in this case.  =
The current spec is written such that these SAs are made before being put i=
nto service, which requires the three-way handshake.  However, I am not sur=
e that the second update (A to tell B to use interface_2's address as a pre=
ferred address) would be a three way handshake, since no address verificati=
on needs to take place (if there is already an SA set up to that interface)=
.  Instead, it may just be a two-way handshake.

But I agree with you that it may be better in some cases to just have a sin=
gle three-way handshake when an address needs to be put into service.  It m=
ay also be the case that a host's other (non-preferred) addresses can be ad=
vertised during the base exchange and not require the separate three-way ha=
ndshake.

>
> It is no doubt that host B knows several available addresses of host A
> is useful. These addresses can be used for load sharing or
> fault-tolerant. As described above, it seems like current HIP
> multihoming solution fails to handle this flexible. If a
> interface/address switching mechanism is adopted, the switching can be
> more efficient.

We discussed the future of multihoming at the Anaheim meeting.   As you obs=
erved, multihoming is somewhat underspecified in RFC 5206.  We agreed to fo=
cus the revision of RFC 5206 on mobility, and again leave a more detailed m=
ultihoming specification as a second phase work effort.   There was also se=
ntiment expressed that the current suggestion in RFC 5206 to proactively se=
t up all pairs of SAs between all addresses is excessive.

> Does anyone know if there are solutions related to HIP
> multihomed host's interface/address switching except rfc5206?
>
It has been discussed in the past that the shim6 failure detection and loca=
tor selection protocol (RFC 5534) could be applied to HIP multihoming use c=
ases.  Also, the shim6 API document relates to HIP multihoming:  http://too=
ls.ietf.org/html/draft-ietf-shim6-multihome-shim-api-13

Also, Mika Kousa and Baris Boyvat's theses discuss multihoming:
http://infrahip.hiit.fi/index.php?index=3Dpublications

- Tom