IP Addressing is Broken for VM Mobile capable Clouds

I have been thinking that IP addressing is sort of broken when
it comes to Clouds. A lot of people in my former company have been thinking
about this (needless to say). I am going to paraphrase some thoughts and
write-ups we've had in this space. Although extending Layer 2 as widely
as possible solves a lot of problems, it doesn't solve the general
"private to public" or "public to public" problem. You always get back
to routing in the capital-I Internet.

It all starts with the fact that, in a highly virtualized environment,
IP address space explodes. Everything has multiple IP addresses; servers
have IP addresses for management, for the physical NICs, for all of the
virtual machines and the virtual NIC therein, and if any virtual
appliances are installed they have multiple IP addresses as well.

Several areas are of concern here, on the one hand, the IPv4 address
space simply starts to run out. Consider an environment inside the Cloud
which has 1M actual servers. As explained above, assuming a 16 core
server, each server could have 32 VM's, and each VM could have a handful
of IP addresses associated with it (virtual NICs, etc). That could
easily explode to a Cloud with well over 32M IP addresses. Even using
Network Address Translation (NAT), the 24-bit Class A reserved Private
Network Range provides a total address space of only 16M unique IP
addresses!

For this reason many Cloud operators are considering switching to IPv6
which provides for a much larger local address space in the trillions of
unique IP addresses. Switching to IPv6 is quite an undertaking, and some
believe that switching from one static addressing scheme to another
static addressing scheme (eg IPv4 to IPv6) might not be the right
approach in a large highly virtualized environment such as Cloud
Computing. If one is reconsidering addressing, one should consider the
Mobility aspects of VMs in Cloud.

VM Mobility provides for new challenges in any static addressing scheme.
When one moves a running VM from one location to another, the IP address
goes with the running VM and any application runtimes hosted by the VM.
IP addresses (of either traditional type) embody both Location and
Identity in the IP address, eg, routers and switches use the form of the
IP address not only to identify uniquely the endpoint, but by virtual of
decoding the address, infer the Location of the endpoint (and how to
reach that endpoint using switching and routing protocols). So while an
addressing scheme is being reconsidered, let's consider two schemes
which embody Mobility.

You might think that Mobile IPv4 <http://www.ietf.org/rfc/rfc3344.txt>
and Mobile IPv6 <http://www.ietf.org/rfc/rfc3775.txt> mechanisms can be
used in this case. Because IP addresses in either case are still
provider-supplied and follow top level address allocations, we still
find VM mobility issues when a VM attempts more general mobility from
one Cloud provider to another for example.

In an attempt to completely generalize the addressing solution, a
completely dynamic scheme where Location and Identification have been
separated has been developed. This new scheme is called Location
Identity Separation Protocol
<http://tools.ietf.org/html/draft-farinacci-lisp-10> (LISP). LISP based
systems can interwork with both IPv4 and IPv6 based networks, through
protocol support on edge routers. However, internal to a Cloud, which
may in itself span several geographies, LISP addressing may be used.

The basic idea behind the Loc/ID split is that the current Internet
routing and addressing architecture combines two functions: Routing
Locators (RLOCs), which describe how a device is attached to the
network, and Endpoint Identifiers (EIDs), which define "who" the device
is, in a single numbering space, the IP address. Proponents of the
Loc/ID split argue that this "overloading" of functions places the
constraints on end-system use of addresses that we detailed. Splitting
these functions apart by using different numbering spaces for EIDs and
RLOCs yields several advantages, including improved scalability of the
routing system through greater aggregation of RLOCs. To achieve this
aggregation, we must allocate RLOCs in a way that is congruent with the
topology of the network. EIDs, on the other hand, are typically
allocated along organizational boundaries.

Because the network topology and organizational hierarchies are rarely
congruent, it is difficult (if not impossible) to make a single
numbering space efficiently serve both purposes without imposing
unacceptable constraints (such as requiring renumbering upon provider
changes) on the use of that space. LISP, as a specific instance of the
Loc/ID split, aims to decouple location and identity. This decoupling
will facilitate improved aggregation of the RLOC space, implement
persistent identity in the EID space, and hopefully increase the
security and efficiency of network mobility.

Although LISP isn't in routers yet, it is alive <http://www.lisp4.net/>
and open <http://gforge.info.ucl.ac.be/projects/openlisp> ,
it may be just what the doctor ordered for the IP addressing 'challenge'
in Clouds.