Re: [Hipsec] Selection of LSI address block

Miika Komu <miika.komu@hiit.fi> Thu, 20 August 2009 21:34 UTC

Return-Path: <miika.komu@hiit.fi>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBCA43A6FB2 for <hipsec@core3.amsl.com>; Thu, 20 Aug 2009 14:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 DEnXIR3hAck4 for <hipsec@core3.amsl.com>; Thu, 20 Aug 2009 14:34:58 -0700 (PDT)
Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id CFF3928C17D for <hipsec@ietf.org>; Thu, 20 Aug 2009 14:34:41 -0700 (PDT)
Received: from ip104.infrahip.net (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id 1C2C525ED16 for <hipsec@ietf.org>; Fri, 21 Aug 2009 00:34:47 +0300 (EEST)
Message-ID: <4A8DC176.3000608@hiit.fi>
Date: Fri, 21 Aug 2009 00:34:46 +0300
From: Miika Komu <miika.komu@hiit.fi>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: hip WG <hipsec@ietf.org>
References: <4A8CF111.5010901@hiit.fi> <4A8D2557.4060705@htt-consult.com> <77F357662F8BFA4CA7074B0410171B6D0A8B7264@XCH-NW-5V1.nw.nos.boeing.com>
In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D0A8B7264@XCH-NW-5V1.nw.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Hipsec] Selection of LSI address block
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: miika.komu@hiit.fi
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2009 21:34:59 -0000

Henderson, Thomas R wrote:

Hi,

>> -----Original Message-----
>> From: Robert Moskowitz [mailto:rgm@htt-consult.com] 
>> Sent: Thursday, August 20, 2009 3:29 AM
>> To: miika.komu@hiit.fi
>> Cc: hipsec@ietf.org
>> Subject: Re: [Hipsec] Selection of LSI address block
>>
>> Miika Komu wrote:
>>> Ahrenholz, Jeffrey M wrote:
>>>
>>> Hi,
>>>
>>>>> We have discussed using 127.0.0.0 for LSIs, say 
>> 127.100.0.0/16, but 
>>>>> will that really work?
>>>> in the OpenHIP software we have a macro IN_LOOP() to check 
>> if an IPv4
>>>> address is equal to (INADDR_LOOPBACK >> IN_CLASSA_NSHIFT), i.e. if 
>>>> the top bits equal 127
>>>> (see /usr/include/netinet/in.h on Linux)
>>>>
>>>> I wonder if other applications use similar techniques to check for
>>>> loopback addresses? Using 127.100.0.0/16 would be 
>> problematic in that
>>>> case.
>>> many apps probably (?) just check 127.0.0.0/8 which could be a big 
>>> problem for HIP. I would prefer getting a slot from 
>> 1.0.0.0/x address 
>>> space to avoid such problems. We have been experimenting with the 
>>> 1.0.0.0/x address space without any problems. 
>> Then we need to make an official request from IANA.
>>
>>
>> It should come from our chairs. But some text from our 
>> developers as to 
>> why 127 won't work MAY be of value.
>>
> 
> For use within the host only, I think it would be nice to get an
> allocation for this type of usage, but I don't think it is strictly
> required.  It seems to me that the main requirement for LSIs is to use a
> range of 32-bit numbers that can be distinguished from destination IP
> addresses reachable from the host, but that are not in the range of
> special IP addresses (224/8, 127/8) that might be checked by
> applications.  The other consideration is that some other overlay on the
> host is not using those same numbers (i.e. they need to be locally
> deconflicted).  Use of private address space or just squatting on some
> other prefix like within 240/8 should also work and be permitted in the
> specifications (i.e. should be a matter of local deployments). 
> 
> For use within a larger scope, such as a site, an address range in an
> existing private address block might be the best choice.
> 
> If there is a request for special allocation, it might help to note that
> the need is more general than HIP and that other overlays could use
> this; i.e. maybe something like an "HID" (host identifier) prefix for
> IPv4, of which HIP is one use case.

sorry, but I'd disagree on using private address realms for LSI. IMHO, 
the private address space is the worst choice for three reasons:

1) You have to guess which one private address space is unoccupied for NATs.
2) Mobility can cause more conflicts with the selection of the LSI 
prefix selection. Implementations would have to handle dynamic 
renumbering of the LSI prefix and it would be a mess!
3) Management for LSIs without a fixed prefix would be more complicated 
for ACLs in legacy apps. It makes the administrators life more complicated.

The 1.0.0.0 prefix is the least problematic and 127.0.0.0 is the second 
best, IMHO.