Re: [Hipsec] Selection of LSI address block

["Henderson, Thomas R" <[e-mail]>]

 

> -----Original Message-----
> From: Miika Komu [mailto:[e-mail]] 
> Sent: Thursday, August 20, 2009 2:35 PM
> To: hip WG
> Subject: Re: [Hipsec] Selection of LSI address block
> 
> Henderson, Thomas R wrote:
> 
> > For use within a larger scope, such as a site, an address 
> range in an
> > existing private address block might be the best choice.
> > 
> 
> 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.

Yes, I agree that if all private addresses are in use in a site, or one
cannot determine which addresses are likely to be active, then private
space may not be a good choice.  However, many sites where HIP may be
deployed may not otherwise use private space at all.  Also, note that
some applications (e.g. virtual machine monitors) already scan networks
for unused private subnets and start using them once a vacant one is
found.

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

Yes, if you are roaming into unknown networks, this would be a bad
choice.

> 3) Management for LSIs without a fixed prefix would be more 
> complicated 
> for ACLs in legacy apps. It makes the administrators life 
> more complicated.
> 

What kind of ACLs in applications are you thinking of?

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

I agree that if we can obtain a full /8 for LSIs or host identities,
that would be easiest.  I'm not sure 127/8 is preferable to private
space for the reasons Jeff mentioned, but it probably should be tested.
If we were to obtain a smaller prefix such as /16, it probably would
still be OK but would reduce the likelihood that LSIs could easily be
randomly generated (such as using the low order bits of the HIT) without
collisions.

I would be willing to amend my previous statement such as:

For use within a larger scope, such as a site, an address range in an
existing private address block might be the best choice, unless the
host may, in the future, move to or obtain an address on a network 
that uses such private addressing.

Anyway, it is not going to affect interoperability if an implementation
chooses an unused private address block, an unallocated block, or
something like Net1.

Tom