Re: sockets APIs extensions for Host Identity Protocol

Keith Moore <moore@cs.utk.edu> Fri, 11 May 2007 21:47 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmcxx-0005SB-BF; Fri, 11 May 2007 17:47:57 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hmcxw-0005S6-N8 for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 17:47:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmcxv-0005Ry-Gw for discuss@apps.ietf.org; Fri, 11 May 2007 17:47:56 -0400
Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmcxu-0005qA-8g for discuss@apps.ietf.org; Fri, 11 May 2007 17:47:55 -0400
Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id D2A75CB3E0; Fri, 11 May 2007 17:47:53 -0400 (EDT)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09dY026FQE43; Fri, 11 May 2007 17:47:37 -0400 (EDT)
Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 7323CCB3EA; Fri, 11 May 2007 17:47:37 -0400 (EDT)
Message-ID: <4644E478.1070804@cs.utk.edu>
Date: Fri, 11 May 2007 17:47:36 -0400
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Miika Komu <miika@iki.fi>
Subject: Re: sockets APIs extensions for Host Identity Protocol
References: <Pine.SOL.4.64.0705041801060.14418@kekkonen.cs.hut.fi> <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <Pine.LNX.4.64.0705091449360.26169@hermes-1.csi.cam.ac.uk> <4641D94C.9070304@cs.utk.edu> <Pine.SOL.4.64.0705102013550.10049@kekkonen.cs.hut.fi> <46436B10.5090706@cs.utk.edu> <Pine.SOL.4.64.0705102159020.10049@kekkonen.cs.hut.fi> <4643F873.3000501@cs.utk.edu> <Pine.SOL.4.64.0705110851440.24038@kekkonen.cs.hut.fi> <46442588.7020405@cs.utk.edu> <Pine.SOL.4.64.0705111344130.16213@kekkonen.cs.hut.fi> <4644779F.60805@cs.utk.edu> <Pine.SOL.4.64.0705111801430.8816@kekkonen.cs.hut.fi> <4644CD76.10900@cs.utk.edu> <Pine.SOL.4.64.0705112330070.8816@kekkonen.cs.hut.fi> <4644D90B.1020304@cs.utk.edu> <Pine.SOL.4.64.0705120006150.8816@kekkonen.cs.hut.fi>
In-Reply-To: <Pine.SOL.4.64.0705120006150.8816@kekkonen.cs.hut.fi>
X-Enigmail-Version: 0.95.0
OpenPGP: id=E1473978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

Miika Komu wrote:
> On Fri, 11 May 2007, Keith Moore wrote:
>
>> please no.  don't try to hide this stuff from the app in the low-level
>> API.   the rest of the network keeps trying to force routing decisions
>> on the apps in the absence of routing information.  ideally, the app
>> shouldn't have to be doing any routing or address selection or
>> anything.  but at present, how to cope with this kind of world is an
>> unsolved problem, and the only place where experimentation can be done
>> towards learning how to solve that problem is at layer 7.    if you
>> cripple the API, you prevent that kind of experimentation (at worst) or
>> (at best) increase the burden on the app writer by forcing him to write
>> his own kernel extensions.
>>
>> that, and you still need to expose IP addresses for diagnostic purposes.
>>
>> what do you gain from trying to hide the IP addresses?
>
> First, to discourage the use of IP addresses as referrals because
> application developer would have to fetch them using a separate
> function call. But maybe this is a weak justification... Second, the
> socket address structure is constrained to 255 bytes. It will fit
> "only" 1 HIT and 15 addresses. Is this enough for e.g. routers?
perhaps strangely, the latter justification makes more sense to me.  no,
15 addresses is not enough.  but it's not acceptable to have the IP
addresses passed implicitly from the resolver to the socket.  offhand,
I'd say that a good compromise would be to allow some reasonable number
of addresses to be specified using sockaddr_hip and to allow more peer
addresses to be added using a setsockopt() call.