ANIMA M. Behringer
Internet-Draft Cisco Systems
Intended status: Standards Track October 16, 2015
Expires: April 18, 2016
An Autonomic IPv6 Addressing Scheme
draft-behringer-anima-autonomic-addressing-02
Abstract
This document describes a generic IPv6 addressing scheme which is
suitable for self-managing Autonomic Control Plane. The scheme
allows for a flat address hierarchy as well as optionally, when
required, the definition of aggregatable zones.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Behringer Expires April 18, 2016 [Page 1]
Internet-Draft Autonomic Addressing October 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Fundamental Concepts of Autonomic Addressing . . . . . . . . 2
3. The Base Addressing Scheme . . . . . . . . . . . . . . . . . 3
4. Possible Sub-Schemes . . . . . . . . . . . . . . . . . . . . 4
4.1. Sub-Scheme 1 . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Sub-Scheme 2 . . . . . . . . . . . . . . . . . . . . . . 5
5. Usage of the Zone Field . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
In an Autonomic Network, as defined in
[I-D.irtf-nmrg-autonomic-network-definitions], and specified in more
detail in [I-D.behringer-anima-reference-model], one of the design
goals is to minimise central functions.
In an autonomic network each node receives a domain-unique
identifier, which consists of a domain name and a unique node-ID in
that domain. We introduce an addressing scheme and an algorithm that
allows the calculation of a unique IPv6 ULA address from those
parameters. In other words, once a device has a unique node-ID and
domain name, this addressing scheme and algorithm allows for
distributed self-management of addressing inside a network.
The addressing scheme described here is specifically designed for the
Autonomic Control Plane (ACP; see
[I-D.ietf-anima-autonomic-control-plane]). It is for communication
inside the domain only, specifically to support self-management
functions. It may be used for OAM functions inside the ACP as well,
as described in [I-D.eckert-anima-stable-connectivity].
2. Fundamental Concepts of Autonomic Addressing
We assume that each node has a unique domain name and a unique node
ID inside that domain. The fundamental concepts for autonomic
addressing are:
o IPv6 only: Autonomic processes should use exclusively IPv6, for
simplicity reasons.
o Usage: Autonomic addresses are exclusively used for self-
management functions inside a trusted domain. They are not used
Behringer Expires April 18, 2016 [Page 2]
Internet-Draft Autonomic Addressing October 2015
for user traffic. Communications with entities outside the
trusted domain use another address space, for example normally
managed routable address space.
o Separation: Autonomic address space is used separately from user
address space and other address realms. This supports the
robustness requirement.
o Loopback-only: Only loopback interfaces of autonomic nodes carry a
routable address; all other interfaces exclusively use IPv6 link
local for autonomic functions. The usage of IPv6 link local
addressing is discussed in [RFC7404].
o Use-ULA: For loopback interfaces of autonomic nodes, we use Unique
Local Addresses (ULA), as specified in [RFC4193]. An alternative
scheme was discussed, using assigned ULA addressing. The
consensus was to use standard ULA, because it was deemed to be
sufficient.
o No external connectivity: They do not provide access to the
Internet. If a node requires further reaching connectivity, it
should use another, traditionally managed address scheme in
parallel.
3. The Base Addressing Scheme
The Base ULA addressing scheme for autonomic nodes has the following
format:
8 40 3 77
+--+--------------+------+------------------------------------------+
|FD| hash(domain) | Type | (sub-scheme) |
+--+--------------+------+------------------------------------------+
Figure 1: Base Addressing Scheme
The first 48 bits follow the ULA scheme, as defined in [RFC4193], to
which a type field is added:
o "FD" identifies a locally defined ULA address.
o The "global ID" is set here to be a hash of the domain name, which
results in a pseudo-random 40 bit value. It is calculated as the
first 40 bits of the MD5 hash of the domain name, in the example
"example.com".
o Type: Set to 000 (3 zero bits). This field allows different
address sub-schemes in the future. The goal is to start with a
Behringer Expires April 18, 2016 [Page 3]
Internet-Draft Autonomic Addressing October 2015
minimal number (ideally one) of sub-schemes initially, but to
allow for extensions later if and when required. This addresses
the "upgradability" requirement. Assignment of types for this
field should be maintained by IANA.
4. Possible Sub-Schemes
The sub-schemes listed here are not intended to be all supported
initially, but are listed for discussion. The final document should
define ideally only a single sub-scheme for now, and leave the other
"types" for later assignment.
4.1. Sub-Scheme 1
51 13 64
+------------------------+---------+--------------------------------+
| (base scheme) | Zone ID | Device ID |
+------------------------+---------+--------------------------------+
Figure 2: Addressing Scheme 1
The fields are defined as follows: [Editor's note: The lengths of the
fields is for discussion.]
o Zone ID: If set to all zero bits: The device ID bits are used as
an identifier (as opposed to a locator). This results in a non-
hierarchical, flat addressing scheme. Any other value indicates a
zone. See section Section 5 on how this field is used in detail.
o Device ID: A unique value for each device.
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:
o 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.
o 16 bit: Device number, a number which is unique for a given
registrar, to identify the device. This can be a sequentially
assigned number.
The "device ID" itself is unique in a domain (i.e., the Zone-ID is
not required for uniqueness). Therefore, a device can be addressed
either as part of a flat hierarchy (zone ID = 0), or with an
Behringer Expires April 18, 2016 [Page 4]
Internet-Draft Autonomic Addressing October 2015
aggregation scheme (any other zone ID). A address with zone-ID could
be interpreted as an identifier, with another zone-ID as a locator.
See Section 5 for a description of the zone bits.
4.2. Sub-Scheme 2
51 13 64-V ?
+------------------------+---------+----------------------------+---+
| (base scheme) | Zone ID | Device ID | V |
+------------------------+---------+----------------------------+---+
Figure 3: Addressing Scheme 2
The fields are defined as follows: [Editor's note: The lengths of the
fields is for discussion.]
o Zone ID: As in sub-scheme 1.
o Device ID: As in sub-scheme 1.
o V: Virtualization bit(s): 1 or more bits that indicate a virtual
context on an autonomic node.
In addition the scheme 1 (Section 4.1), this scheme allows the direct
addressing of specific virtual containers / VMs on an autonomic node.
An increasing number of hardware platforms have a distributed
architecture, with a base OS for the node itself, and the support for
hardware blades with potentially different OSs. The VMs on the
blades could be considered as separate autonomic nodes, in which case
it would make sense to be able to address them directly. Autonomic
Service Agents (ASAs) could be instantiated in either the base OS, or
one of the VMs on a blade. This addressing scheme allows for the
easy separation of the hardware context.
The location of the V bit(s) at the end of the address allows to
announce a single prefix for each autonomic node, while having
separate virtual contexts addressable directly.
5. Usage of the Zone Field
The "zone ID" allows for the introduction of structure in the
addressing scheme.
Zone = zero is the default addressing scheme in an autonomic domain.
Every autonomic node MUST respond to its ACP address with zone=0.
Used on its own this leads to a non-hierarchical address scheme,
which is suitable for networks up to a certain size. In this case,
Behringer Expires April 18, 2016 [Page 5]
Internet-Draft Autonomic Addressing October 2015
the addresses primarily act as identifiers for the nodes, and
aggregation is not possible.
If aggregation is required, the 13 bit value allows for up to 8191
zones. The allocation of zone numbers may either happen
automatically through a to-be-defined algorithm; or it could be
configured and maintained manually. [We could divide the zone space
into manual and automatic space - to be discussed.]
If a device learns through an autonomic method or through
configuration that it is part of a zone, it MUST also respond to its
ACP address with that zone number. In this case the ACP loopback is
configured with two ACP addresses: One for zone 0 and one for the
assigned zone. This method allows for a smooth transition between a
flat addressing scheme and an hierarchical one.
(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.)
Note: Another way to introduce hierarchy is to use sub-domains in the
naming scheme. The node names "node17.subdomainA.example.com" and
"node4.subdomainB.example.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.
6. IANA Considerations
The type field in the base addressing scheme should be maintained by
IANA.
7. Security Considerations
tbc
8. Acknowledgements
The following people have been involved in developing this scheme:
Toerless Eckert, Steinthor Bjarnason, BL Balaji, Ravi Kumar
Vadapalli.
9. References
Behringer Expires April 18, 2016 [Page 6]
Internet-Draft Autonomic Addressing October 2015
[I-D.behringer-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Liu, B., Jeff, J., and J. Strassner, "A Reference Model
for Autonomic Networking", draft-behringer-anima-
reference-model-03 (work in progress), June 2015.
[I-D.eckert-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-
eckert-anima-stable-connectivity-01 (work in progress),
March 2015.
[I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An
Autonomic Control Plane", draft-ietf-anima-autonomic-
control-plane-01 (work in progress), October 2015.
[I-D.irtf-nmrg-autonomic-network-definitions]
Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking - Definitions and Design Goals", draft-irtf-
nmrg-autonomic-network-definitions-07 (work in progress),
March 2015.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014,
<http://www.rfc-editor.org/info/rfc7404>.
Author's Address
Michael H. Behringer
Cisco Systems
Building D, 45 Allee des Ormes
Mougins 06250
France
Email: mbehring@cisco.com
Behringer Expires April 18, 2016 [Page 7]