[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Hipsec] Selection of LSI address block



Henderson, Thomas R wrote:

Hi,

-----Original Message-----
From: Robert Moskowitz [mailto:rgm at htt-consult.com] Sent: Thursday, August 20, 2009 3:29 AM
To: miika.komu at hiit.fi
Cc: hipsec at 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.