Autonomic Control Plane Based on IPv4
draft-du-anima-ipv4-acp-00

Abstract

This document describes an Autonomic Control Plane (ACP) based on IPv4. The ACP is an overlay control plane logically separate from the data plane. It is established autonomically independent of the operator's configurations. This document introduces the approach of using IPv4 addresses for the routing in an ACP.

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 January 23, 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.

Table of Contents

• 1. Introduction
• 2. Requirements Language and Terminology
• 3. Overview
• 4. Issues Needed to be Considered and Possible Solutions
• 4.1. Link-local Address
• 4.2. Link-local Multicast
• 4.3. Addressing Inside the ACP
• 4.4. Autonomic Address Configuration
• 4.5. Routing Protocol
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. Change log [RFC Editor: Please remove]
• 9. References
• Authors' Addresses

1. Introduction

Autonomic Control Plane (ACP) provides a secure and always-on communication plane. It is one of the infrastructure functions for Autonomic Network (AN). Autonomic Service Agents in the autonomic network can use ACP to discover or negotiate. The background to Autonomic Network is described in [RFC7575] and [RFC7576].

An IPv6-based ACP has been proposed in [I-D.behringer-anima-autonomic-control-plane], and it is suggested that ACP should rely exclusively on IPv6. In this approach, the ACP is organized as a pure IPv6 network, while the network data plane can be based on any protocol, including IPv4 or IPv6. The advantages of this approach are no need to support dual stack IPv4/v6, better self-configuration ability of IPv6, etc.

IPv6 is the best candidate for the ACP, but it should not be precluded to provide an IPv4 based ACP for the operator as an option. When the network data plane is running IPv4, an IPv4 based ACP can offer better compatibility, which means no need to run IPv4 in the data plane, and IPv6 in the control plane.

The purpose of this document is to address the issues that arise if an IPv4 based ACP is considered needed, including clarifying the additional requirements and solutions compared to the IPv6 one.

{Editor notes: an operator, who has difficulties to upgrade the whole network to IPv6, maybe wants an IPv4 based ACP to simplify the management jobs. This document makes sense for the network operators who have an essential requirement to simple the network management, but have a less urgent requirement to upgrade to IPv6. Hence, defining an IPv4 based ACP is helpful for the deployment of Autonomic Network, or at least harmless.}

{Editor notes: It should be noticed that ACP can work while the data plane is unchanged, i.e., remaining IPv4, because ACP and AN have been designed as transparent as possible, which means the operator will rarely notice them. However, it is not always true in practice. The network operator may need to maintain two address systems in this case, for examples, when developing or debugging, or in network monitoring, or if connecting to an IPv4 server for the ACP is needed.}

2. Requirements Language and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as [RFC2119] key words.

Autonomic Control Plane:

A self-forming, self-managing and self-protecting control plane used in the Autonomic Network, which is inband on the network, yet as independent as possible of configuration, addressing and routing problems.

Autonomic Function:

A feature or function which requires no configuration, and can derive all required information either through self-knowledge, discovery or through Intent.

Autonomic Node:

A node which employs exclusively Autonomic Functions.

Autonomic Network:

A network containing exclusively Autonomic Nodes. It may contain one or several Autonomic Domains.

Autonomic Service Agent:

An agent implemented on an Autonomic Node which implements an Autonomic Function.

3. Overview

Steps of constructing an IPv4 based Autonomic Control Plane are as follows.

• Each Autonomic Node has a vendor specific Unique Device Identifier (UDI) or IDevID certificate, based on which it joins the autonomic domain, and obtains a domain certificate.
• Based on the domain certificate, an Autonomic Node authenticates the discovered neighbors and establishes a secure tunnel with each of them.
• Each Autonomic Node maintains a virtual routing and forwarding instance, and owns a loopback IPv4 addresses.
• Through the tunnels established in the previous steps, a routing protocol is run, and each Autonomic Node establishes its ACP routing table which is separated from the global routing table.

The following figurer illustrates the ACP.

           autonomic node 1                  autonomic node 2
          ...................               ...................
   secure .                 .   secure      .                 .  secure
   tunnel :  +-----------+  :   tunnel      :  +-----------+  :  tunnel
   ..--------| ACP VRF   |---------------------| ACP VRF   |---------..
          : / \         / \   <--routing-->   / \         / \ :
          : \ /  IPv4   \ /                   \ /  IPv4   \ / :
   ..--------| loopback  |---------------------| loopback  |---------..
          :  +-----------+  :               :  +-----------+  :
          :                 :               :                 :
          :  +-----------+  :               :  +-----------+  :
          :  |  global   |  :               :  |  global   |  :
          :  |  routing  |  : <--routing--> :  |  routing  |  :
          :  |           |  :               :  |           |  :
   ..........| data plane|.....................| data plane|...........
          :  +-----------+  :    link       :  +-----------+  :
          :.................:               :.................:

       Figure 1 Overview of the IPv4 Based Autonomic Control Plane

IPv4 has a link-local address mechanism defined in [RFC3927]. Either those link-local addresses can be used for an IPSec tunnel to be established, or the MACSec channels can be used here to encrypt the control traffic hop-by-hop.

4. Issues Needed to be Considered and Possible Solutions

{Editor notes: It is not complete. Further discussions are needed.}

4.1. Link-local Address

In IPv6, a network node will acquire a valid link-local address without any pre-configuration. These link-local addresses are used by the Autonomic Node to set up tunnels with their neighbors in IPv6 based ACP.

As mentioned before, IPv4 has a link-local address mechanism. However, according to [RFC3927], this address is only used when no IP address is manually configured on the interface and no DHCP server is found. In addition, that document does not recommend that IPv4 link-local addresses and routable addresses be configured simultaneously on the same interface.

Therefore, it brings in some troubles for an IPv4 ACP to establish a secure channel with neighbors using link-local addresses.

4.2. Link-local Multicast

In the IPv6 ACP, link-local multicast is suggested to be used in the adjacency discovery. In IPv4 ACP, perhaps a multicast in L2 may be considered instead of the link-local multicast based on the IPv6 link-local address.

4.3. Addressing Inside the ACP

In the IPv6 ACP, Unique Local Addresses (ULA) specified in [RFC4193] is suggested to be used as the overlay addresses of autonomic nodes in the ACP.

IPv4 has the private IP address space, such as 10/8; however, it is maybe not statistically unique inside the AS.

4.4. Autonomic Address Configuration

In the IPv6 ACP, the ULA address can be self-configured. This feature is important in the Autonomic network. However, there is no mechanism for self-configuration of IPv4 addresses. The length of an IPv4 address is much shorter than an IPv6 one, which causes a larger possbility of confilcting in the address self-configuration.

4.5. Routing Protocol

In the IPv6 ACP, RPL is proposed for the routing protocol. However, it does not have an IPv4 version. Perhaps OSPF or ISIS can be used in an IPv4 ACP.

5. Security Considerations

Relevant security issues can be found in [I-D.behringer-anima-autonomic-control-plane].

6. IANA Considerations

Currently, this document reuqestes no action by IANA.

7. Acknowledgements

Valuable comments were received from Bing Liu.

This document was produced using the xml2rfc tool [RFC2629].

8. Change log [RFC Editor: Please remove]

draft-du-anima-ipv4-acp-00: original version, 2015-07-xx.

9. References

Authors' Addresses