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

Shinta Sugimoto <> Thu, 14 October 2010 03:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C08E3A685B for <>; Wed, 13 Oct 2010 20:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.898
X-Spam-Level: **
X-Spam-Status: No, score=2.898 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rgqJLAMlwTsy for <>; Wed, 13 Oct 2010 20:06:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF8C43A6832 for <>; Wed, 13 Oct 2010 20:06:20 -0700 (PDT)
Received: from localhost.localdomain (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by (Postfix) with ESMTPSA id 09B6E2780A4; Thu, 14 Oct 2010 12:07:36 +0900 (JST)
Message-ID: <>
Date: Thu, 14 Oct 2010 12:01:54 +0900
From: Shinta Sugimoto <>
User-Agent: Thunderbird (X11/20070809)
MIME-Version: 1.0
To: "Henderson, Thomas R" <>
References: <20100816114202.1241.59079.idtracker@localhost> <4C692876.60802@> <> <4C69DE84.8010 7> <> <> <> <86C69B19-D385-46A9-B116-5EE198273305@apnic.n e t> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'Miika Komu' <>, 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: Thu, 14 Oct 2010 03:06:22 -0000

Hi Thomas,

Henderson, Thomas R wrote:


>> For the above reason, I think that we cannot use SHIM_LOC_LOCAL_SEND
>> socket option (or ancillary data) for the purpose of specifying the
>> initial peer locator for the HIP case.
>> If there is a need for application to specify the initial locator, it
>> should be a defined separately, I think. And that is HIP
>> specific. The
>> scope of this document is to define a *common* set of API
>> required for
>> HIP and SHIM6, so I think it's outside the scope of this
>> document. Comments?
> My sense is that it would be OK to proceed in that manner but that
> we probably need to take a pass through this document and the
> HIP API document to make sure that the scope and relationship
> between the documents is clearer.


> An analogous situation is present in normal sockets in which
> the common socket API has different semantics when the underlying
> transport is datagram or stream.  In that case, there is a family
> of functions (e.g. getprotoent) that can report to the client
> what type of socket it is.  I am wondering whether SHIM_ASSOCIATED
> should be expanded along those lines to tell the client what
> underlying shim type is present (or whether the rules for
> shim context apply or not).

It depends on value that application could get by knowing the type of 
multihoming shim sub-layer (i.e., HIP or SHIM6). I personally cannot 
come up with good usecases.

>>>> 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 wonder how the kernel does not know about the peer locator (IP
>> address) but the application does. You mentioned that
>> application could
>> know the address out-of-band, but how? Do you have good examples?
> I don't have any concrete examples since I don't know of
> any (presently) shim-aware applications, but it is not hard
> to conceive of one in which well-known IP/HIT bindings are
> added to an application configuration file for bootstrapping
> purposes.

OK, I see. Thanks for the clarifications.