<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?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"?>

<rfc ipr="trust200902" docName="draft-behringer-anima-autonomic-addressing-00" category="std"  >

<front>
<title abbrev="Autonomic Addressing">An Autonomic IPv6 Addressing Scheme</title>

<author fullname="Michael H. Behringer" initials="M.H." surname="Behringer">
  <organization>Cisco Systems</organization>
  <address>
    <postal>
      <street>Building D, 45 Allee des Ormes</street>
      <city>Mougins</city>
      <region/>
      <code>06250</code>
      <country>France</country>
    </postal>
    <email>mbehring@cisco.com</email>
  </address>
 </author>

<date day="22" month="April" year="2015" />

<area>Operations and Management</area>
<workgroup>ANIMA</workgroup>

<abstract>
<t>This document describes a generic IPv6 addressing scheme which is suitable for autonomic nodes, where node addressing must not depend on a centrally managed scheme. It assumes a unique domain name and device name, and automatically derives a unique IPv6 address from those. The scheme allows for a flat address hierarchy as well as optionally, when required, the definition of zones which are aggregatable. 
This document is for discussion right now; the final addressing scheme should probably move into <xref target="I-D.behringer-anima-reference-model"/>.
</t>
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction">
<t>
In an Autonomic Network, as defined in <xref target="I-D.irtf-nmrg-autonomic-network-definitions"/>, one of the design goals is to minimise central functions. Address management traditionally is a centralised function, where addresses are assigned to nodes. In this document we assume that each node has already been assigned with a unique node name, and a domain name. We introduce an addressing scheme and an algorithm that allows the calculation of a unique IPv6 ULA address inside a domain. In other words, once a device has a unique node and domain name, this addressing scheme and algorithm allows for distributed self-management of addressing inside a network.</t>

<t>The addressing scheme described here is specifically designed for both the data plane of a network, as well as the Autonomic Control Plane (ACP; see <xref target="I-D.behringer-autonomic-control-plane"/>). It is for communication inside the domain only, specifically to support self-management functions.</t>

<t>This scheme targets exclusively loopback addresses of nodes. We assume that link-local addressing is used on the interfaces of links. </t>

<t>The addressing scheme allows the definitions of zones for the purpose of aggregation of address space. This makes it possible to start with a flat address scheme, and introduce a hierarchy later if and when required. </t>
</section> <!-- intro -->

<section anchor="scheme" title="The Addressing Scheme">
<t>
We assume that each node has two unique properties: 
<list style="symbols">
  <t>A domain name: All devices in a domain share the same domain name. </t>
  <t>A node name: This name MUST be unique inside the domain. </t>
</list></t>
<t>An example of a full node name is "node17.domain.com", where "node17" is the node name and "domain.com" is the domain name. Inside "domain.com" "node17" MUST be unique. </t>
<t>The addressing scheme follows the ULA address definition, as specified in <xref target="RFC4193"/>, and has the following format:</t>
<t><figure title="Address Scheme" anchor='addr_scheme'>
   	<artwork>
  8      40          3       13                    64	           
+--+--------------+------+---------+--------------------------------+
|FD| hash(domain) | Type | Zone ID |         Device ID              |
+--+--------------+------+---------+--------------------------------+
	</artwork>
   </figure>
 </t>
<t>The fields are defined as follows:
<list style="symbols">
  <t>FD: The prefix to indicate that the address is a ULA prefix.</t>
  <t>hash(domain): A pseudo-random 40 bit value representing the domain. See <xref target="calculate"/> for details on the way this value is derived.</t>
  <t>Type: Set to 000. This field allows different address sub-types in the future. </t>
  <t>Zone ID: If set to all zero bits: Flat addressing scheme. Any other value indicates a zone. See section <xref target="hierarchy"/></t>
  <t>Device ID: A unique 64 bit value for the device. See <xref target="calculate"/> for details on the way this value is derived.</t> 
</list>
</t> 
</section> <!-- scheme -->

<section anchor="calculate" title="Algorithm to Calculate Unique Addresses">
<t>The "hash(domain)" part of the address is calculated as the first 40 bits of the MD5 hash of the domain name, in the example "domain.com".</t>
<t>The device ID is derived as follows: In an Autonomic Network, a registrar is enrolling new devices. As part of the enrolment process the registrar assigns a number to the device, which is unique for this registrar, but not necessarily unique in the domain. The 64 bit device ID is then composed as: 
<list style="symbols"> 
  <t>48 bit: Registrar ID, a number unique inside the domain that identifies the registrar which assigned the name to the device. A MAC address of the registrar can be used for this purpose. </t>
  <t>16 bit: Device ID, a number which is unique for a given registrar, to identify the device. This can be a sequentially assigned number. </t> 
</list>
</t>
<t>If required, other schemas can be defined in the future, using a new "type" value. </t>
</section> <!-- calculate -->

<section anchor="hierarchy" title="Address Hierarchy">
<t>The "zone ID" allows for the definition of a simple address hierarchy. If set to zero, the address scheme is flat. In this case, the addresses primarily act as identifiers for the nodes. Used like this, aggregation is not possible. </t>
<t>If aggregation is required, the 13 bit value allows for up to 8191 zones. (Theoretically, the 13 bits for the zone ID would allow also for two levels of zones, introducing a sub-hierarchy. We do not think this is required at this point, but a new type could be used in the future to support such a scheme.)</t>
<t>Another way to introduce hierarchy is to use sub-domains in the naming scheme. The node names "node17.subdomainA.domain.com" and "node4.subdomainB.domain.com" would automatically lead to different ULA prefixes, which can be used to introduce a routing hierarchy in the network, assuming that the subdomains are aligned with routing areas. </t> 
</section> <!-- hierarchy -->

<section anchor="security" title="Security Considerations">
<t>tbc</t>
</section> <!-- security -->

<section anchor="ack" title="Acknowledgements">
<t>The following people have been involved in developing this scheme: Toerless Eckert, Steinthor Bjarnason, BL Balaji, Ravi Kumar Vadapalli.</t>
</section> <!-- ack -->

</middle>

<back>

<references title="References">
<?rfc include='reference.RFC.4193'?>
<?rfc include="reference.I-D.irtf-nmrg-autonomic-network-definitions.xml"?>
<?rfc include="reference.I-D.behringer-anima-reference-model.xml"?>
<?rfc include="reference.I-D.behringer-autonomic-control-plane.xml"?>
</references>

</back>
</rfc>

