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 protected]>: > 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<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. > > > ______________________________**_________________ > Hipsec mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/hipsec<https://www.ietf.org/mailman/listinfo/hipsec> >
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
