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

Shinta Sugimoto <shinta@sfc.wide.ad.jp> Mon, 11 October 2010 15:43 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 0AD9D3A6927 for <shim6@core3.amsl.com>; Mon, 11 Oct 2010 08:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.198
X-Spam-Level: ***
X-Spam-Status: No, score=3.198 tagged_above=-999 required=5 tests=[AWL=2.294, 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 6iBYH4E8HzGy for <shim6@core3.amsl.com>; Mon, 11 Oct 2010 08:43:57 -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 E9AE23A6A9C for <shim6@ietf.org>; Mon, 11 Oct 2010 08:43:56 -0700 (PDT)
Received: from imac.local (softbank126018084155.bbtec.net [126.18.84.155]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6391D278075; Tue, 12 Oct 2010 00:45:06 +0900 (JST)
Message-ID: <4CB33102.7010006@sfc.wide.ad.jp>
Date: Tue, 12 Oct 2010 00:45:06 +0900
From: Shinta Sugimoto <shinta@sfc.wide.ad.jp>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; ja-JP-mac; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Miika Komu <mkomu@cs.hut.fi>
References: <20100816114202.1241.59079.idtracker@localhost> <4C692876.60802@cs.hut.fi> <4535F52C-8E78-4CBE-8983-DD7195722865@apnic.net> <4C69DE84.8010706@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.net> <4CAA425E.2070906@piuha.net> <4CB08B71.4000000@sfc.wide.ad.jp> <4CB22ED9.30204@piuha.net> <4CB2D1FC.9020904@cs.hut.fi>
In-Reply-To: <4CB2D1FC.9020904@cs.hut.fi>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "shim6@ietf.org" <shim6@ietf.org>, Kristian Slavov <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: Mon, 11 Oct 2010 15:43:58 -0000

Hi Miika,

(10/10/11 17:59), Miika Komu wrote:
> Hi,
>
> On 10/11/2010 12:23 AM, Jari Arkko wrote:
>
>>> Peer's locator set
>>> is provided by the peer, and a node cannot propose peer's locator. I
>>> believe it's the same for HIP. Let me clarify this point with Miika
>>> off-line.
>>
>> OK. I think the simplest solution would be to simply forbid the API user
>> from inserting unknown locators. If you want to go beyond that it is of
>> course possible, but will complicate things.
>
> it is a very useful feature if the application can provide at least the
> initial mapping from the destination HIT to the corresponding IP
> address. Contrast to SHIM6, HIP does not have routable ULIDs...
>

Could you please tell me what is the current practice? How the 
destination IP address (locator) is determined on the initiator in 
normal case?

I assume that the kernel first knows the peer's IP address (locator) 
from the DNS. If there are more than one IP address returned, then the 
kernel will pick one, I assume. What motivates application to specify 
the initial peer locator? Why it's *very* useful for application to 
specify the address?

Regards,
Shinta