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

Shinta Sugimoto <shinta@sfc.wide.ad.jp> Thu, 14 October 2010 03:06 UTC

Return-Path: <shinta@sfc.wide.ad.jp>
X-Original-To: shim6@core3.amsl.com
Delivered-To: shim6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C08E3A685B for <shim6@core3.amsl.com>; Wed, 13 Oct 2010 20:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgqJLAMlwTsy for <shim6@core3.amsl.com>; Wed, 13 Oct 2010 20:06:21 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id EF8C43A6832 for <shim6@ietf.org>; Wed, 13 Oct 2010 20:06:20 -0700 (PDT)
Received: from localhost.localdomain (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 09B6E2780A4; Thu, 14 Oct 2010 12:07:36 +0900 (JST)
Message-ID: <4CB672A2.3090600@sfc.wide.ad.jp>
Date: Thu, 14 Oct 2010 12:01:54 +0900
From: Shinta Sugimoto <shinta@sfc.wide.ad.jp>
User-Agent: Thunderbird 2.0.0.6 (X11/20070809)
MIME-Version: 1.0
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
References: <20100816114202.1241.59079.idtracker@localhost> <4C692876.60802@ cs.hut.fi> <4535F52C-8E78-4CBE-8983-DD7195722865@apnic.net> <4C69DE84.8010 7 06@sfc.wide.ad.jp> <4C91D119.5010101@cs.hut.fi> <4C91E946.6080807@sfc.wide.ad.jp> <4C920431.2090603@cs.hut.fi> <86C69B19-D385-46A9-B116-5EE198273305@apnic.n e t> <4CAA425E.2070906@piuha.net> <4CAEB35B.3020107@cs.hut.fi> <4CAEDEAD.9060407@piuha.net> <4CAF01F6.3030905@cs.hut.fi> <7CC566635CFE364D87DC5803D4712A6C4CEC451999@XCH-NW-10V.nw.nos.boeing.com> <4CB56F2F.6040008@sfc.wide.ad.jp> <7CC566635CFE364D87DC5803D4712A6C4CEC4519A5@XCH-NW-10V.nw.nos.boeing.com>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEC4519A5@XCH-NW-10V.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: 'Miika Komu' <mkomu@cs.hut.fi>, shim6 <shim6@ietf.org>, "kristian.slavov@ericsson.com" <kristian.slavov@ericsson.com>
Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2010 03:06:22 -0000

Hi Thomas,

Henderson, Thomas R wrote:
> 

(snip)

>> 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.

OK.

> 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.

Regards,
Shinta