One document matched: draft-du-anima-ipv4-acp-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- 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">
<?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 category="info" docName="draft-du-anima-ipv4-acp-00" ipr="trust200902">
  <front>
    <title abbrev="IPv4 based ACP">Autonomic Control Plane Based on
    IPv4</title>

    <author fullname="Zongpeng Du" initials="Z." surname="Du">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156 Beiqing Road</street>

          <city>Hai-Dian District, Beijing, 100095</city>

          <country>P.R. China</country>
        </postal>

        <email>duzongpeng@huawei.com</email>
      </address>
    </author>

    <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156 Beiqing Road</street>

          <city>Hai-Dian District, Beijing, 100095</city>

          <country>P.R. China</country>
        </postal>

        <email>jiangsheng@huawei.com</email>
      </address>
    </author>

    <date day="" month="" year="2015"/>

    <area>Operations and Management</area>

    <workgroup>ANIMA WG</workgroup>

    <keyword>Autonomic Networking, Autonomic Control Plane</keyword>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>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 <xref target="RFC7575"/> and <xref
      target="RFC7576"/>.</t>

      <t>An IPv6-based ACP has been proposed in <xref
      target="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.</t>

      <t>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.</t>

      <t>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.</t>

      <t>{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.}</t>

      <t>{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.}</t>

      <!-- intro -->
    </section>

    <section anchor="terminology"
             title="Requirements Language and Terminology">
      <t>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 <xref
      target="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 <xref
      target="RFC2119"/> key words.</t>

      <t><list style="hanging">
          <t hangText="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.</t>

          <t hangText="Autonomic Function:">A feature or function which
          requires no configuration, and can derive all required information
          either through self-knowledge, discovery or through Intent.</t>

          <t hangText="Autonomic Node:">A node which employs exclusively
          Autonomic Functions.</t>

          <t hangText="Autonomic Network:">A network containing exclusively
          Autonomic Nodes. It may contain one or several Autonomic
          Domains.</t>

          <t hangText="Autonomic Service Agent:">An agent implemented on an
          Autonomic Node which implements an Autonomic Function.</t>
        </list></t>
    </section>

    <section anchor="overview" title="Overview">
      <t>Steps of constructing an IPv4 based Autonomic Control Plane are as
      follows.</t>

      <t><list style="symbols">
          <t>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.</t>

          <t>Based on the domain certificate, an Autonomic Node authenticates
          the discovered neighbors and establishes a secure tunnel with each
          of them.</t>

          <t>Each Autonomic Node maintains a virtual routing and forwarding
          instance, and owns a loopback IPv4 addresses.</t>

          <t>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.</t>
        </list></t>

      <t>The following figurer illustrates the ACP.</t>

      <figure>
        <artwork><![CDATA[           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
]]></artwork>
      </figure>

      <t/>

      <t>IPv4 has a link-local address mechanism defined in <xref
      target="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.</t>
    </section>

    <section anchor="issue"
             title="Issues Needed to be Considered and Possible Solutions">
      <t>{Editor notes: It is not complete. Further discussions are
      needed.}</t>

      <section title="Link-local Address">
        <t>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.</t>

        <t>As mentioned before, IPv4 has a link-local address mechanism.
        However, according to <xref target="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.</t>

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

      <section title="Link-local Multicast">
        <t>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.</t>
      </section>

      <section title="Addressing Inside the ACP">
        <t>In the IPv6 ACP, Unique Local Addresses (ULA) specified in <xref
        target="RFC4193"/> is suggested to be used as the overlay addresses of
        autonomic nodes in the ACP.</t>

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

      <section title="Autonomic Address Configuration">
        <t>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.</t>
      </section>

      <section title="Routing Protocol">
        <t>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.</t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Relevant security issues can be found in <xref
      target="I-D.behringer-anima-autonomic-control-plane"/>.</t>
    </section>

    <!-- security -->

    <section anchor="iana" title="IANA Considerations">
      <t>Currently, this document reuqestes no action by IANA.</t>
    </section>

    <!-- iana -->

    <section anchor="ack" title="Acknowledgements">
      <t>Valuable comments were received from Bing Liu.</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-du-anima-ipv4-acp-00: original version, 2015-07-xx.</t>
    </section>

    <!-- changes -->
  </middle>

  <back>
    <references title="References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.2629'?>

      <?rfc include='reference.RFC.3927'?>

      <?rfc include='reference.RFC.4193'?>

      <?rfc include='reference.RFC.7575'?>

      <?rfc include='reference.RFC.7576'?>

      <?rfc include='reference.I-D.behringer-anima-autonomic-control-plane'?>
    </references>
  </back>
</rfc>