Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api

Miika Komu <> Wed, 13 October 2010 04:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6CA83A68A8 for <>; Tue, 12 Oct 2010 21:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.387
X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w3x667YQnmJs for <>; Tue, 12 Oct 2010 21:57:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6E0C03A6B37 for <>; Tue, 12 Oct 2010 21:57:04 -0700 (PDT)
Received: from ([] helo=[]) by with esmtp (Exim 4.54) id 1P5tPt-00065q-C5; Wed, 13 Oct 2010 07:58:17 +0300
Message-ID: <>
Date: Wed, 13 Oct 2010 07:59:56 +0300
From: Miika Komu <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: "Henderson, Thomas R" <>
References: <20100816114202.1241.59079.idtracker@localhost> <4C692876.60802@> <> <4C69DE84.80107> <> <> <> < t> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: shim6 <>, "" <>
Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Oct 2010 04:57:08 -0000


On 12/10/10 20:54, Henderson, Thomas R wrote:

>> -----Original Message----- From: Miika Komu
>> [] Sent: Friday, October 08, 2010 4:35 AM To:
>> Jari Arkko Cc: Shinta Sugimoto; shim6;
>>; Henderson, Thomas R Subject: Re:
>> [shim6] AD review of draft-ietf-shim6-multihome-shim-api
> <snip>
>>> However, IIRC in HIP you cannot propose a locator for the other
>>> side, only for yourself. Or is your plan that you move the
>> session to
>>> another locator and that if that node happens to be the
>> wrong one, then
>>> it cannot decrypt the traffic anyway, so there's no damage?
>> (There has to be a successful return routability check before any
>> traffic is transported)
>> There's two use cases:
>> 1. No HIP session (i.e. SHIM context) yet and application knows the
>> IP address of the peer. 2. An existing HIP session, connectivity
>> lost but the application (with the assistance from the user) can
>> help to rediscover the peer.
>> Now remembering this "unknown" part again, I think the MAY was
>> referring to the first case described above. It should be ok for
>> the application give a hint especially in the absence of better
>> knowledge from the SHIM.
> I agree; that was my understanding of the main intent of this clause
> (to allow the application to provide the shim with a hint of the
> binding to IP address).
> However, in reviewing section 6.2, it seems like this would fail
> since there is no shim context for the socket.  If I'm not mistaken,
> the draft seems to forbid applications running in opportunistic HIP
> mode because this API requires that shim context be associated with
> the socket for the ancillary data to be accepted.


"Another use case is to use the opportunistic mode.."

>> Regarding to the case two, it is true that RFC5206 basically
>> assumes that the peer has to announce it's locator set before the
>> local host can use them. I believe the peer can refuse to answer if
>> the local host triggers a return routability check to an
>> unannounced locator of the peer. However, the situation may be
>> changing in RFC5206-bis due to the recent advancements in IPv4-IPv6
>> handovers [1] which are not yet included in RFC5206.
>> Tom, care to comment if I am too proactive here?
>> [1] Secure and efficient IPv4/IPv6 handovers using host-based
>> identifier-locator Split, Samu Varjonen et al, 2009
> The paper does point out a use case for sending data to a previously
> unknown locator-- however, it seems to be slightly different than the
> use case here.  In the paper, the node learns of the address change
> and it seems that the HIP daemon sends an Echo request-- I take this
> to mean that the HIP daemon does this proactively.  Here, we are
> talking about applications triggering this directly and using this
> API to do so since they may have learned of the address out of band?

I stand corrected, setting the destination address should be possible 
only in the beginning of HIP communications between two hosts.