Subject: [Hipsec] allocation of LSI address space

From: Miika Komu <[email-masked]>
Date: Fri, 27 Mar 2009 14:25:29 +0200

Hi,

we have been talking about reserving address space for non-routable 
address in draft-iana-rfc3330bis-06. After some discussion with Robert 
Moskowitz and Antti Louko, I wrote down some straw-man text.

Before you start reading the text, you should notice that it is not HIP 
specific. Also, the "site-local context" is an attempt to extend a 
little bit beyond of current standards for HIP. Perhaps HIP folks can 
think about leasing an LSI from DHCP if you have trouble in picturing an 
use case for the site-local addresses.

Looking forward for comments. Better yet, please rewrite the text if 
you're not happy with it!)

Address Space for Non-routable IPv4 Addresses
---------------------------------------------

Address space 1.0.0.0/8 is reserved for experimental use with flat, 
non-routable IPv4 addresses. An example of such addresses are Local 
Scope Identifiers (LSIs) in Host Identity Protocol [RFC4423, section 
5.4], but the namespace can be used by any other protocol.

The address space is not managed by IANA except for 1.255.255.255 which 
reserved for protocol-specific broadcast. As the namespace is unmanaged, 
the namespace is not collision free and the addresses are valid only 
within a local context. Local context refers either to a host or site 
context as explained below. Selection of the context depends on the 
underlying protocol making use of the 1.0.0.0/8 address space and, 
hence, it is out of scope of this document.

In host-local context, an address valid only within the local host. The 
local and peer address assignment is managed by the local system.

In site-local context, an address is valid within an administrative 
domain consisting of a number of hosts. The addresses are distributed 
for the hosts using a centralized (or distributed) mechanism by the site.

When an address from host-local or site-local context leaks to another 
context, it MUST be considered invalid. Detection of context leaks are 
protocol specific and therefore not specified herein.

The address allocation policy in both host-local and site-local context 
has to follow two rules. First, the policy MUST NOT partition the 
address space into subprefixes. Second, the policy MUST be based on 
random allocation of new addresses. The reason for this address 
allocation policy is to avoid namespace collision upon the event when 
namespaces of two or more sites are joined together.

The address space reserves a relatively large namespace for non-routable 
IPv4 addresses. A large namespace is necessary for two reasons. First, 
the same address space is used by multiple protocols and each protocol 
may want to separate addresses from each other. Second, the large 
namespace lowers collision probabilities when sites with large number of 
routable addresses are joined together.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 30 Mar 2009 17:45:48 -0400

> Moskowitz and Antti Louko, I wrote down some straw-man text.

I am going to put on an IANA hat, for discuss purposes.

>
> Before you start reading the text, you should notice that it is not 
> HIP specific. Also, the "site-local context" is an attempt to extend a 
> think about leasing an LSI from DHCP if you have trouble in picturing 
> an use case for the site-local addresses.
>
> non-routable IPv4 addresses.

ICANN is hurting. They are under pressure to move 1.0.0.0/8 from
reserved to unassigned. That is they are going to have IANA allocate
Net1 to RIRs and let any 25+ year old problems surface and be dealt with.

> An example of such addresses are Local Scope Identifiers (LSIs) in 
> Host Identity Protocol [RFC4423, section 5.4], but the namespace can 
> be used by any other protocol.
>
> The address space is not managed by IANA except for 1.255.255.255 
> which reserved for protocol-specific broadcast. As the namespace is 
> unmanaged, the namespace is not collision free and the addresses are 
> valid only within a local context. Local context refers either to a 
> host or site context as explained below. Selection of the context 
> depends on the underlying protocol making use of the 1.0.0.0/8 address 
> space and, hence, it is out of scope of this document.
>
> In host-local context, an address valid only within the local host. 
> The local and peer address assignment is managed by the local system.

This is what 127.0.0.0/8 is for use it.

> for the hosts using a centralized (or distributed) mechanism by the site.

This is what RFC1918 allocated addresses are for, use them.

> The address allocation policy in both host-local and site-local 
> context has to follow two rules. First, the policy MUST NOT partition 
> the address space into subprefixes. Second, the policy MUST be based 
> on random allocation of new addresses. The reason for this address 
> The address space reserves a relatively large namespace for 
> non-routable IPv4 addresses. A large namespace is necessary for two 
> reasons. First, the same address space is used by multiple protocols 
> and each protocol may want to separate addresses from each other. 
> Second, the large namespace lowers collision probabilities when sites 
> with large number of routable addresses are joined together. 

For our purposes, we need to look real hard if 127.255.0.0/16 will work
for us and various apps won't hickup with this new use of Net127. If we
need more space consider 127.192.0.0/14 or even 127.128.0.0/12.

We need to have the data on hand as to why Net127 does not work before
we ask for space in Net1.

If Net127 DOES meet our needs, we still need to educate IANA on this so
that it can be recorded in 3330bis for posperity. And given the timing
for 3330bis, we need to act fast. In fact can our chairs inform IANA
that we have this concern, to actually posting a last-call comment on
ietf mailing list?

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 27 Mar 2009 16:40:51 -0400

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 30 Mar 2009 22:03:44 -0700

Hi, I had a few comments also on this proposal (inline below).   I would
also be fine with Robert's suggestion for 127.255/16, or for RFC1918
addresses in some HIP proxy situations.

> Address Space for Non-routable IPv4 Addresses

Many people use the term non-routable for RFC1918 addresses, which is
not what I think you meant (but would be fine with me-- see above).

> protocol specific and therefore not specified herein.

I do not see the point of the above paragraph, plus if you are arguing
for generating them randomly, and that they must be flat, how is a
context leak detected?

> namespaces of two or more sites are joined together.

I don't see the point for restricting the above.  We found it convenient
to use non random LSIs in some of our experiments, such as 1.0.0.1,
1.0.0.2, etc.  I would rather just say that random allocation is one
technique to reduce collisions and leave it at that.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Tue, 31 Mar 2009 08:17:12 +0300

Henderson, Thomas R wrote:

Hi,

> addresses in some HIP proxy situations.

no strong objections on /16 either (it is better than nothing). I tried 
to argument why /8 would be more useful in the text.

> for generating them randomly, and that they must be flat, how is a

The above paragraph was not very important. Detecting leaks is a hard 
problem and shouldn't be discussed in the text.

> technique to reduce collisions and leave it at that.

Right.