Subject: [Hipsec] 5201-bis LSI address allocation

From: Robert Moskowitz <[email-masked]>
Date: Thu, 08 Nov 2012 14:59:55 -0500

In 5201-bis we should specify the LSI address range.

Net1 has been allocated to APNIC 
(http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml). 
Alternatives mentioned are:

1) dynamically select from 1918 address space like VMs do (but this does 
not play well with mobility)

2) Use a /16 (we did discuss this earlier with the opinion that a /16 
would be large enough) in 127/8.  Say 127.9/16 (it could even be a /10, 
see below)?

3) Request IANA make an assignment from the class E range.

4) Follow precedence set in RFC 6598 for a /10 allocation, but this 
requires finding a kind owner of address space that would give it up for 
this purpose.

Let's agree on this, then Tom and I will add a section on it into 5201-bis.

---

From: Tobias Heer <[email-masked]>
Date: Fri, 09 Nov 2012 10:12:09 +0100

Hello Robert,

the question that I just asked myself is: why is it necessary to define the
LSI space? After all, the adresses are only local and should not leave the
host. So for interoperability between HIP  hosts it should not matter.
However...

Of course, the address space should not collide with any other address
space on the host. So coexistence  with different applications DOES matter.
For this purpose, wouldn't it be enough to give a solid recommendation for
a good address space? I agree that the basis for such a recommendation is a
specific allocation. However, I think it should be a "SHOULD use" in the
final text.

With the goal of coexistence in mind, I would pledge for a HIP-only address
space. Using the same space as many VMs do will cause trouble and won't
benefit coexistence.

Regarding the size of the address space. Using a /16 may not be enough for
some server applications that serve different hosts with high frequency.
However, in such case, the administrator could locally define a different
larger space and rule out collisions with other applications locally (if we
use the "SHOULD use" phrase). Therefore,  for typical applications, I would
support a /16 as recommendation.

I hope these thoughts help to make a good decision.

BR,

Tobias
Am 08.11.2012 20:59 schrieb "Robert Moskowitz" <[email-masked]>:

> Net1 has been allocated to APNIC (http://www.iana.org/**
> assignments/ipv4-address-**space/ipv4-address-space.xml<http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml>).
> would be large enough) in 127/8.  Say 127.9/16 (it could even be a /10, see
> below)?
>
> ______________________________**_________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/hipsec<https://www.ietf.org/mailman/listinfo/hipsec>
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 09 Nov 2012 09:49:15 -0500

On 11/09/2012 02:12 AM, Tobias Heer wrote:
>
> Hello Robert,
>
> the question that I just asked myself is: why is it necessary to 
> define the LSI space? After all, the adresses are only local and 
> should not leave the host. So for interoperability between HIP  hosts 
> it should not matter. However...
>
> space on the host. So coexistence  with different applications DOES 
> matter. For this purpose, wouldn't it be enough to give a solid 
> recommendation for a good address space? I agree that the basis for 
> such a recommendation is a specific allocation. However, I think it 
> should be a "SHOULD use" in the final text.
>

It will definitely be a SHOULD for whatever address space we work out.

> With the goal of coexistence in mind, I would pledge for a HIP-only 
> address space. Using the same space as many VMs do will cause trouble 
> and won't benefit coexistence.
>
> Regarding the size of the address space. Using a /16 may not be enough 
> for some server applications that serve different hosts with high 
> frequency. However, in such case, the administrator could locally 
> define a different larger space and rule out collisions with other 
> applications locally (if we use the "SHOULD use" phrase). Therefore,  
> for typical applications, I would support a /16 as recommendation.
>

I spoke with Andrew McGregor, Tim Shepard, and our new ID, Brian 
Haberman about this.  The focus seems to be 127 or Class E.

127.10/10, is one option, but according to Andrew and Tim, kernels tend 
to turn off TCP congestion control for a 127 address.  This would be a 
challenge.

Brian is interested in the Class E space.  There ARE problems of packets 
just being dropped if a Class E address was in the IP source address 
field, but LSIs only occur in places like the TCB.  A bit more research 
will be needed on using Class E.  If Brian comes back that this may be a 
way forward, we probably should have some real testing over the next 
couple weeks that it will really work before we put it in 5201-bis (and 
get the address space marked as 'reserved for local use'.

> BR,
>
> Tobias
>
> Am 08.11.2012 20:59 schrieb "Robert Moskowitz" <[email-masked] 
> <mailto:[email-masked]>>:
> >
> > 1) dynamically select from 1918 address space like VMs do (but this 
> does not play well with mobility)
> >
> > 2) Use a /16 (we did discuss this earlier with the opinion that a 
> /16 would be large enough) in 127/8.  Say 127.9/16 (it could even be a 
> /10, see below)?
> >
> requires finding a kind owner of address space that would give it up 
> for this purpose.
> >
> > _______________________________________________
> > Hipsec mailing list
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 9 Nov 2012 08:06:36 -0800

We'll test class E with OpenHIP and report back later; that seems preferable to me since 127/8 seems tied to localhost (RFC 3330) and RFC 1918 addresses are private routable addresses and aggressively deployed in some environments.

- Tom