<?xml version="1.0" encoding="UTF-8"?>

<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->

<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
     (which supports the latest, sometimes undocumented and under-tested, features.) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!-- You need one entry like the following for each RFC referenced -->

<!ENTITY RFC2119 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC1918 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml'>
<!ENTITY RFC2629 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY RFC2460 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
<!ENTITY RFC6437 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6437.xml'>
<!ENTITY RFC6438 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6438.xml'>
<!ENTITY RFC6434 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6434.xml'>
<!ENTITY RFC6296 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6296.xml'>
<!ENTITY RFC4864 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4864.xml'>
<!ENTITY RFC2991 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2991.xml'>
<!ENTITY RFC4193 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>

<!-- You need one entry like the following for each I-D referenced -->


<!ENTITY DRAFT-nvo3-prob SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-nvo3-overlay-problem-statement.xml"> 

<!ENTITY DRAFT-nvo3-frame SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lasserre-nvo3-framework.xml">

<!ENTITY DRAFT-nvo3-overl SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kreeger-nvo3-overlay-cp.xml">

<!ENTITY DRAFT-ula SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.liu-v6ops-ula-usage-analysis.xml">


]>


<?rfc toc="yes"?>            <!-- You want a table of contents -->
<?rfc symrefs="yes"?>        <!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>       <!-- This sorts the references -->
<?rfc iprnotified="no" ?>    <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>


<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-carpenter-nvo3-addressing-00" category="info" >


<front>
<title abbrev="NVO3 Addresssing">Layer 3 Addressing Considerations for Network Virtualization Overlays</title>


<author initials="B. E." surname="Carpenter" fullname="Brian Carpenter">
    <organization abbrev="Univ. of Auckland"></organization>
    <address>
      <postal>
        <street>Department of Computer Science</street>
        <street>University of Auckland</street>
        <street>PB 92019</street>
        <city>Auckland</city>
        <region></region>
        <code>1142</code>
        <country>New Zealand</country>
      </postal>
      
      <email>brian.e.carpenter@gmail.com</email>
    </address>
</author>




   <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>
      <address>
        <postal>
          <street>Q14, Huawei Campus</street>
          <street>No.156 Beiqing Road</street>
          <city>Hai-Dian District, Beijing</city>
          <code>100095</code>
          <country>P.R. China</country>
        </postal>
        <email>jiangsheng@huawei.com</email>
      </address>
    </author>

 <date day="4" month="July" year="2012" />

<area>Routing</area>
<workgroup>NVO3</workgroup>

 


<abstract>

<t>This document discusses network layer addressing issues for virtual network overlays
in large scale data centres hosting many virtual servers for multiple customers. </t>
    
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction">
<t>A common technique in large data centres hosting servers and services for many customers
is to use virtual layer 3 network overlays (NVO3) to organise, manage and separate the virtual
servers used by individual customers. The related problems are discussed in
<xref target="I-D.narten-nvo3-overlay-problem-statement"/>, and a framework for the main
components of a solution is described in <xref target="I-D.lasserre-nvo3-framework"/>. </t>

<t>[Note: In this draft we do not yet give detailed references to the various NVO3 drafts,
none of which discuss addressing issues in detail.]
</t>

<t>When emulating a large number of virtual hosts on whatever physical
network topology is used, probably involving multiple LAN segments, virtual LANs at layer2,
and both routers and switches, the question of the IP addressing scheme for the virtual
hosts is not trivial. The intention of the present document is to describe the resulting
consequences for IP address management in such an environment. Firstly the general
aspects are discussed, and then the consequences for both IPv4 and IPv6 addressing
schemes are described. </t>

</section> <!-- intro -->

<section anchor="aspects" title="Aspects of addressing in virtual overlay networks">

<section anchor="indep" title="Address Independence and Isolation">

<t>In a typical hosting centre, there will be a number of customers, who are quite
possibly mutual competitors who happen to use the same hosting centre. It is essential
that virtual hosts assigned to one customer cannot communicate directly with, or even
be aware of, virtual hosts assigned to any other customer. It is also essential
that virtual networks are operationally independent to the maximum possible extent. </t>

<t>Therefore, to simplify
operations by clearly separating independent virtual networks (VNs) from one another, and
to enhance both real and perceived confidentiality of each network, it is desirable
for the addresses used by each virtual layer 3 network to be allocated and managed 
independently of all the others. A consequence of this is that it becomes reasonably 
straightforward to configure layer 3 routing such that traffic from one VN can never 
unintentionally enter another one, because each network has its own well defined
range of addresses. Similarly, it is also reasonably straightforward to 
configure firewalls or filters to detect and block any unwanted traffic between VNs, even if
there is a routing misconfiguration. </t> 

<t>For these reasons alone, it is necessary for each VN to have its own well-defined
layer 3 address space that is managed independently of all other VNs. This requirement
is independent of whether the physical hosts that contain the virtual hosts are on one
or more physical or bridged LANs or VLANs. In other words, once the layer 3 topology
is virtualised, layer 2 address independence and isolation is neither necessary
nor sufficient to guarantee layer 3 address independence and isolation. </t>

<t>It should be understood that independent address allocation does not imply
unique addresses. In the IPv4 context, as further discussed below, it is very
likely that multiple VNs will use the same ambiguous address space, running over
the same physical network infrastructure. </t>


</section> <!-- indep -->
<section anchor="mult" title="Multiple Data Centres">

<t>A given customer might have virtual hosts spread across multiple data centres (DCs).
Furthermore, those data centres might be owned and operated by competing enterprises. 
The only safe assumption is that a single address range cannot span multiple DCs,
and that a virtual host being relocated to another DC might need to be renumbered. 
The addressing scheme
for virtual hosts must be compatible with such a situation. Most likely this means extending
the requirement for address independence and isolation to cover separate parts of a given
customer's total set of virtual servers. In other words the usage scenario for any given
customer must be able to deal with virtual hosts in multiple independent and mutually
isolated layer 3 address spaces, and with the risk of occasional virtual host renumbering.
 </t>

<t>This complicates the issues of routing configuration and address filtering. If a VN extends
over multiple DCs, VN routing across DC borders must be supported for the address ranges concerned,
and address filtering must also be applied in a consistent way at each DC hosting part of a given VN. </t>

</section> <!-- mult -->


<section anchor="map" title="Address mapping">

<t>Several of the NVO3 documents state the need for an address mapping scheme. 
Some aspects of this are discussed in <xref target="I-D.kreeger-nvo3-overlay-cp"/>.
It is generally assumed that an NVO3 system will be built using tunnels, and the
required mapping is between virtual host addresses and tunnel end points.
The addressing scheme for virtual hosts needs to be consistent with the
mapping system adopted and whatever dynamic update protocol is used for that
mapping.
 </t>
<t>In the case of a VN that covers multiple DCs, the mapping scheme must also
support multiple DCs. The mapping update protocol will need to exchange mapping
information between tunnel endpoints at all DCs involved. This information needs
to be specified in some detail, and it must be decided whether
this protocol needs to be run per VN or per DC, how this protocol decides which
DCs it should talk with, etc. </t>
</section> <!-- map -->

<section anchor="migr" title="Address migration">

<t>As discussed in <xref target="I-D.narten-nvo3-overlay-problem-statement"/>, 
current virtual host mechanisms assume that a host's IP address is fixed. If
a workload is migrated from one physical host to another, the migration
mechanisms assume that existing transport layer associations such as TCP sessions
stay alive, and the succesful migration of a job in progress relies
on this. </t>


<t>As workload conditions change in a large data centre, virtual hosts may need
to be migrated from one physical host to another, and quite possibly this will
mean moving to a different physical LAN. However, the virtual
host address itself should remain constant as just mentioned. The addressing scheme
adopted needs to be consistent with this requirement. Another way to view this is as
an inverted form of renumbering - instead of the address of a given host
changing, a given address is reassigned to a different physical host, thereby
representing the move of a given virtual host. </t>

<t>When such a move occurs, there will normally be changes in both the
layer 2/layer 3 mapping (given by ARP, Neighbour Discovery, etc.) and the
virtual host address to tunnel mapping mentioned above. However,
an address which is moved in this way should still
remain part of the same aggregate for routing purposes. Otherwise, an immediate
change to the routing configuration will be needed as well. </t>

<t>As mentioned above, if a virtual host needs to be migrated between DCs,
it might be unavoidable for its virtual address to change. In this case
an application layer mechanism will be needed to recover from the resulting
loss of transport layer sessions. </t>

</section> <!-- migr -->

<section anchor="dns" title="DNS">

<t>A Domain Name Service, which resolves queries for hostnames into IP addresses, can reduce the direct
dependence of customer applications on IP addresses. If a virtual host is always connected using 
its hostname, the renumbering issue during inter-DC migrations, mentioned in previous section,
would be significantly mitigated. However, this would imply a need for rapid DNS updates. </t>

</section> <!-- dns -->

<section anchor="dual" title="Dual Stack Operation">

<t>In the case of a dual stack deployment, where each virtual host has both an IPv4 and an IPv6
address, there will presumably be some sort of interdependency of the two addressing schemes.
At least, the virtual subnet topologies would usually be the same for the two addressing
schemes, and virtual hosts would need to migrate simultaneously for IPv4 and IPv6 purposes. If this
was not the case, scenarios requiring IPv4/IPv6 interworking might arise unexpectedly,
which would be inconvenient and inefficient. A particular case would be the migration
of a virtual host between two DCs, one of which supports dual stack and the other of which
supports only a single stack. </t>

<t>In general, these situations would require a layer 3 IPv4/IPv6 translator within a VN.
This solution should be avoided if possible. </t>

</section> <!-- dual -->

</section> <!-- aspects -->

<section anchor="cons4" title="Consequences for IPv4 address management">


<t>In IPv4, it must be assumed that in many if not most cases, the virtual hosts
will be numbered out of ambiguous private address space <xref target="RFC1918"/>. The only safe assumption
for a general model is that any individual VN may use the same address space as
any other. This increases the importance of the requirements for address isolation,
independence and mapping. In fact, without address mapping (and in some scenarios
network address translation) a large scale IPv4 NVO3 system could not be made to work.
</t>

<t>Since the IPv4 addresses in use will be ambiguous, management tools must be
carefully designed so that operators will never need to rely on addresses alone to identify
individual servers. For example, when an address is presented to an operator for
any reason, it should always be tagged with some sort of VN identifier. The same goes
for any place that an address is logged or stored for any other reason. Legacy
software and tools that do not do this should be avoided as much as possible. </t>

<t>An interesting aspect of using, say, Net 10 for every VN instance is that the number
of virtual hosts can be quite large, up to 2**24 (in excess of 16 million). This frees 
the designer from traditional limits on the size of an IPv4 subnet. </t>

<t>An unavoidable consequence of using RFC1918 addresses is that the virtual hosts,
if accessed by outside users, will be hidden behind either an application layer
proxy or a NAT. In both cases these might be part of a load balancing system. </t>

</section> <!-- cons4 -->

<section anchor="cons6" title="Consequences for IPv6 address management">

<t>In IPv6, there is no concept of ambiguous private space. Each VN can have its
own global-scope address prefix. This removes the operational problems
casued by ambiguous addresses in IPv4. </t>

<t>Even a basic /64 prefix would allow for
more virtual host addresses than would ever be possible in IPv4, so
again the designer is not restricted by any absolute limit on subnet size. 
Nevertheless, it is advisable to use a shorter prefix such as /48 or /56
for each VN, so that a VN can span more than one LAN using standard
IPv6 routing without difficulty. It is unclear that tunnels and address
mapping are needed for IPv6-based VNs, due to the absence of ambiguous
addresses. </t>

<t>A choice can be made between a regular IPv6 prefix from the customer's own
IPv6 space or from ISP-assigned space, and a Unique Local Address prefix
<xref target="RFC4193"/>, <xref target="I-D.liu-v6ops-ula-usage-analysis"/>.
The latter has the advantage of needing no administrative procedure before
assigning it, and it is also routinely blocked by site and ISP border routers,
like an RFC1918 prefix. However, apart from that the choice of IPv6 prefix
has little external importance and is mainly a matter of convenience.
 </t>

<t>There is no requirement for IPv6 prefix translation <xref target="RFC6296"/>
between the virtual hosts and any outside users. However, the presence
of such translation, or of some form of load balancing, cannot be excluded. </t>

</section> <!-- cons6 -->



<section anchor="security" title="Security Considerations">

<t>Routing configurations and filters in firewalls and routers should be
constructed such that, by default, packets from virtual hosts in one VN cannot be
forwarded into another VN. Traffic to and from a given VN should only be allowed
for the designated users of that VN, and for the VN management and operations
tools. </t>

<t>An independent and isolated addressing scheme is not by itself a security
solution. While it might avoid the most trivial and straightforward
penetration attempts, it is in no way a substitute for a security solution
that responds to specific threat models in the NVO3 situation.  </t>

 
</section> <!-- security -->


<section anchor="iana" title="IANA Considerations">
   <t>This document requests no action by IANA. </t>
</section> <!-- iana -->




<section anchor="ack" title="Acknowledgements">

<t>
Valuable comments and contributions were made by
...
and others.
 </t>

<t>This document was produced using the xml2rfc tool
<xref target="RFC2629"/>.</t>

</section> <!-- ack -->


<section anchor ="changes" title="Change log [RFC Editor: Please remove]">


<t>draft-carpenter-nvo3-addressing-00: original version, 2012-07-04.</t>


</section> <!-- changes -->

</middle>

<back>

<references title="Normative References">

&RFC2460;
&RFC1918;
&RFC4193;



</references>

<references title="Informative References">

&RFC2629;
&RFC6296;
&DRAFT-nvo3-prob;
&DRAFT-nvo3-frame;
&DRAFT-nvo3-overl;
&DRAFT-ula;

  
</references>




</back>
</rfc>

