Re: sockets APIs extensions for Host Identity Protocol

Miika Komu <miika@iki.fi> Sun, 13 May 2007 17:18 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 1HnHiJ-00040n-Ja; Sun, 13 May 2007 13:18:31 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnHiI-00040i-T6 for discuss-confirm+ok@megatron.ietf.org; Sun, 13 May 2007 13:18:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnHiI-00040a-Je for discuss@apps.ietf.org; Sun, 13 May 2007 13:18:30 -0400
Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnHiF-0007Yl-8s for discuss@apps.ietf.org; Sun, 13 May 2007 13:18:30 -0400
Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0BE6E2D4F; Sun, 13 May 2007 20:18:22 +0300 (EEST)
X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322
X-Spam-Niksula: No
Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 7D1B12D48; Sun, 13 May 2007 20:18:21 +0300 (EEST)
Date: Sun, 13 May 2007 20:18:21 +0300 (EEST)
From: Miika Komu <miika@iki.fi>
X-X-Sender: mkomu@kekkonen.cs.hut.fi
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Subject: Re: sockets APIs extensions for Host Identity Protocol
In-Reply-To: <200705122150.RAA01766@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <Pine.SOL.4.64.0705132006150.17713@kekkonen.cs.hut.fi>
References: <Pine.SOL.4.64.0705041801060.14418@kekkonen.cs.hut.fi> <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> <200705122107.RAA01505@Sparkle.Rodents.Montreal.QC.CA> <Pine.SOL.4.64.0705130022380.27730@kekkonen.cs.hut.fi> <200705122150.RAA01766@Sparkle.Rodents.Montreal.QC.CA>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
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

On Sat, 12 May 2007, der Mouse wrote:

>>>> Second, the socket address structure is constrained to 255 bytes.
>>> This limit borders on trivial to raise.
>>> Well, unless you're trying to do this on an OS whose source is
>>> closed to you, which I submit is a bad vehicle for such research for
>>> exactly this kind of reason.
>> Why is it "trivial" to raise?
>
> Just change sa_len, sin_len, sin6_len, sun_len, etc, to short instead
> of char.  (You may want to rearrange the element order for better
> packing, but that's not essential, just helpful.)
>
>> I think it will raise all sorts of backwards compatibility problems.
>
> Only if you expect to recompile only part of the world.  There might be
> code lurking that "knows" those fields max out at 255, but I'd say it's
> already broken.

Not all of the applications are open source. This change would break 
binary applications which is not very nice. The change would affect all 
sockets, not just HIP based sockets.

> When (if) it comes to releasing OSes with the new _len fields, it gets
> a little more interesting, but I'd just version the affected calls and
> ignore the issue.

I don't think that storing of 1 vs. N locators justifies this kind of 
a backwards incompatibility change. It is also a huge deployment barrier.

-- 
Miika Komu                                       http://www.iki.fi/miika/