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

Miika Komu <mkomu@cs.hut.fi> Tue, 12 October 2010 04:12 UTC

Return-Path: <mkomu@cs.hut.fi>
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 272283A68B3 for <shim6@core3.amsl.com>; Mon, 11 Oct 2010 21:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.356
X-Spam-Level:
X-Spam-Status: No, score=-6.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9qLJs6ieNC5p for <shim6@core3.amsl.com>; Mon, 11 Oct 2010 21:12:30 -0700 (PDT)
Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 2444E3A68A8 for <shim6@ietf.org>; Mon, 11 Oct 2010 21:12:27 -0700 (PDT)
Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1P5WF8-0004Yk-En; Tue, 12 Oct 2010 07:13:38 +0300
Message-ID: <4CB3E0D0.6020709@cs.hut.fi>
Date: Tue, 12 Oct 2010 07:15:12 +0300
From: Miika Komu <mkomu@cs.hut.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
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> <4CB33102.7010006@sfc.wide.ad.jp> <4CB3831C.900@gmail.com>
In-Reply-To: <4CB3831C.900@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; 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: Tue, 12 Oct 2010 04:12:42 -0000

Hi,

On 12/10/10 00:35, Brian E Carpenter wrote:
> On 2010-10-12 04:45, Shinta Sugimoto wrote:
>> 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?
>
> RFC 3484, or whatever the implementor has chosen to do if they
> don't like RFC 3484.

yes, in the case of multiple destination locators, this could be used. 
At the moment, I am just more concerned that there is no locators at all.

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

There's three problems associated with this.

First, this would assume that the resolver is HIP capable (i.e. can 
resolve HIP records from DNS) but this requirement has not been included 
in the draft at all. While the HIP implementations are offering such 
service for the OS, this is not a standard service implemented by the 
operating system.

Second, the draft is defining *native* APIs for SHIM layers but the 
draft is still assuming legacy resolving APIs underneath while I would 
like to make them independent of each other:

http://tools.ietf.org/html/rfc5338#section-3.2

Third, the native HIP API draft is in the RFC editor queue and it is 
assuming that this feature is available for multiple use cases as 
clearly stated here:

http://tools.ietf.org/html/draft-ietf-hip-native-api-12#section-4.6

Another use case for supporting initial peer locators is P2P-SIP with 
HIP support, for which, there are two implementations (HIIT and 
Ericsson). There, the locator information can be derived from the SIP 
messages. DHT messages or perhaps even from SRV records from the future 
(which aren't supported by any of the HIP resolver software yet) instead 
of the standard HIP records.

So, we have a long story behind the "MAY":

"If the shim sub-layer turns out to be HIP, the HIP implementation MAY 
accept the request for using unknown destination locator"

So, I would suggest to keep it there or maybe even change it to SHOULD.