idnits 2.17.1 draft-du-anima-ipv4-acp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 22, 2015) is 3200 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG Z. Du 3 Internet-Draft S. Jiang 4 Intended status: Informational Huawei Technologies Co., Ltd 5 Expires: January 23, 2016 July 22, 2015 7 Autonomic Control Plane Based on IPv4 8 draft-du-anima-ipv4-acp-00 10 Abstract 12 This document describes an Autonomic Control Plane (ACP) based on 13 IPv4. The ACP is an overlay control plane logically separate from 14 the data plane. It is established autonomically independent of the 15 operator's configurations. This document introduces the approach of 16 using IPv4 addresses for the routing in an ACP. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 23, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language and Terminology . . . . . . . . . . . . 3 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Issues Needed to be Considered and Possible Solutions . . . . 4 56 4.1. Link-local Address . . . . . . . . . . . . . . . . . . . 5 57 4.2. Link-local Multicast . . . . . . . . . . . . . . . . . . 5 58 4.3. Addressing Inside the ACP . . . . . . . . . . . . . . . . 5 59 4.4. Autonomic Address Configuration . . . . . . . . . . . . . 5 60 4.5. Routing Protocol . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 6 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 Autonomic Control Plane (ACP) provides a secure and always-on 71 communication plane. It is one of the infrastructure functions for 72 Autonomic Network (AN). Autonomic Service Agents in the autonomic 73 network can use ACP to discover or negotiate. The background to 74 Autonomic Network is described in [RFC7575] and [RFC7576]. 76 An IPv6-based ACP has been proposed in 77 [I-D.behringer-anima-autonomic-control-plane], and it is suggested 78 that ACP should rely exclusively on IPv6. In this approach, the ACP 79 is organized as a pure IPv6 network, while the network data plane can 80 be based on any protocol, including IPv4 or IPv6. The advantages of 81 this approach are no need to support dual stack IPv4/v6, better self- 82 configuration ability of IPv6, etc. 84 IPv6 is the best candidate for the ACP, but it should not be 85 precluded to provide an IPv4 based ACP for the operator as an option. 86 When the network data plane is running IPv4, an IPv4 based ACP can 87 offer better compatibility, which means no need to run IPv4 in the 88 data plane, and IPv6 in the control plane. 90 The purpose of this document is to address the issues that arise if 91 an IPv4 based ACP is considered needed, including clarifying the 92 additional requirements and solutions compared to the IPv6 one. 94 {Editor notes: an operator, who has difficulties to upgrade the whole 95 network to IPv6, maybe wants an IPv4 based ACP to simplify the 96 management jobs. This document makes sense for the network operators 97 who have an essential requirement to simple the network management, 98 but have a less urgent requirement to upgrade to IPv6. Hence, 99 defining an IPv4 based ACP is helpful for the deployment of Autonomic 100 Network, or at least harmless.} 102 {Editor notes: It should be noticed that ACP can work while the data 103 plane is unchanged, i.e., remaining IPv4, because ACP and AN have 104 been designed as transparent as possible, which means the operator 105 will rarely notice them. However, it is not always true in practice. 106 The network operator may need to maintain two address systems in this 107 case, for examples, when developing or debugging, or in network 108 monitoring, or if connecting to an IPv4 server for the ACP is 109 needed.} 111 2. Requirements Language and Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 [RFC2119] when they appear in ALL CAPS. When these words are not in 117 ALL CAPS (such as "should" or "Should"), they have their usual 118 English meanings, and are not to be interpreted as [RFC2119] key 119 words. 121 Autonomic Control Plane: A self-forming, self-managing and self- 122 protecting control plane used in the Autonomic Network, which is 123 inband on the network, yet as independent as possible of 124 configuration, addressing and routing problems. 126 Autonomic Function: A feature or function which requires no 127 configuration, and can derive all required information either 128 through self-knowledge, discovery or through Intent. 130 Autonomic Node: A node which employs exclusively Autonomic 131 Functions. 133 Autonomic Network: A network containing exclusively Autonomic Nodes. 134 It may contain one or several Autonomic Domains. 136 Autonomic Service Agent: An agent implemented on an Autonomic Node 137 which implements an Autonomic Function. 139 3. Overview 141 Steps of constructing an IPv4 based Autonomic Control Plane are as 142 follows. 144 o Each Autonomic Node has a vendor specific Unique Device Identifier 145 (UDI) or IDevID certificate, based on which it joins the autonomic 146 domain, and obtains a domain certificate. 148 o Based on the domain certificate, an Autonomic Node authenticates 149 the discovered neighbors and establishes a secure tunnel with each 150 of them. 152 o Each Autonomic Node maintains a virtual routing and forwarding 153 instance, and owns a loopback IPv4 addresses. 155 o Through the tunnels established in the previous steps, a routing 156 protocol is run, and each Autonomic Node establishes its ACP 157 routing table which is separated from the global routing table. 159 The following figurer illustrates the ACP. 161 autonomic node 1 autonomic node 2 162 ................... ................... 163 secure . . secure . . secure 164 tunnel : +-----------+ : tunnel : +-----------+ : tunnel 165 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 166 : / \ / \ <--routing--> / \ / \ : 167 : \ / IPv4 \ / \ / IPv4 \ / : 168 ..--------| loopback |---------------------| loopback |---------.. 169 : +-----------+ : : +-----------+ : 170 : : : : 171 : +-----------+ : : +-----------+ : 172 : | global | : : | global | : 173 : | routing | : <--routing--> : | routing | : 174 : | | : : | | : 175 ..........| data plane|.....................| data plane|........... 176 : +-----------+ : link : +-----------+ : 177 :.................: :.................: 179 Figure 1 Overview of the IPv4 Based Autonomic Control Plane 181 IPv4 has a link-local address mechanism defined in [RFC3927]. Either 182 those link-local addresses can be used for an IPSec tunnel to be 183 established, or the MACSec channels can be used here to encrypt the 184 control traffic hop-by-hop. 186 4. Issues Needed to be Considered and Possible Solutions 188 {Editor notes: It is not complete. Further discussions are needed.} 190 4.1. Link-local Address 192 In IPv6, a network node will acquire a valid link-local address 193 without any pre-configuration. These link-local addresses are used 194 by the Autonomic Node to set up tunnels with their neighbors in IPv6 195 based ACP. 197 As mentioned before, IPv4 has a link-local address mechanism. 198 However, according to [RFC3927], this address is only used when no IP 199 address is manually configured on the interface and no DHCP server is 200 found. In addition, that document does not recommend that IPv4 link- 201 local addresses and routable addresses be configured simultaneously 202 on the same interface. 204 Therefore, it brings in some troubles for an IPv4 ACP to establish a 205 secure channel with neighbors using link-local addresses. 207 4.2. Link-local Multicast 209 In the IPv6 ACP, link-local multicast is suggested to be used in the 210 adjacency discovery. In IPv4 ACP, perhaps a multicast in L2 may be 211 considered instead of the link-local multicast based on the IPv6 212 link-local address. 214 4.3. Addressing Inside the ACP 216 In the IPv6 ACP, Unique Local Addresses (ULA) specified in [RFC4193] 217 is suggested to be used as the overlay addresses of autonomic nodes 218 in the ACP. 220 IPv4 has the private IP address space, such as 10/8; however, it is 221 maybe not statistically unique inside the AS. 223 4.4. Autonomic Address Configuration 225 In the IPv6 ACP, the ULA address can be self-configured. This 226 feature is important in the Autonomic network. However, there is no 227 mechanism for self-configuration of IPv4 addresses. The length of an 228 IPv4 address is much shorter than an IPv6 one, which causes a larger 229 possbility of confilcting in the address self-configuration. 231 4.5. Routing Protocol 233 In the IPv6 ACP, RPL is proposed for the routing protocol. However, 234 it does not have an IPv4 version. Perhaps OSPF or ISIS can be used 235 in an IPv4 ACP. 237 5. Security Considerations 239 Relevant security issues can be found in 240 [I-D.behringer-anima-autonomic-control-plane]. 242 6. IANA Considerations 244 Currently, this document reuqestes no action by IANA. 246 7. Acknowledgements 248 Valuable comments were received from Bing Liu. 250 This document was produced using the xml2rfc tool [RFC2629]. 252 8. Change log [RFC Editor: Please remove] 254 draft-du-anima-ipv4-acp-00: original version, 2015-07-xx. 256 9. References 258 [I-D.behringer-anima-autonomic-control-plane] 259 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 260 Autonomic Control Plane", draft-behringer-anima-autonomic- 261 control-plane-03 (work in progress), June 2015. 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 269 DOI 10.17487/RFC2629, June 1999, 270 . 272 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 273 Configuration of IPv4 Link-Local Addresses", RFC 3927, 274 DOI 10.17487/RFC3927, May 2005, 275 . 277 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 278 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 279 . 281 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 282 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 283 Networking: Definitions and Design Goals", RFC 7575, 284 DOI 10.17487/RFC7575, June 2015, 285 . 287 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 288 Analysis for Autonomic Networking", RFC 7576, 289 DOI 10.17487/RFC7576, June 2015, 290 . 292 Authors' Addresses 294 Zongpeng Du 295 Huawei Technologies Co., Ltd 296 Q14, Huawei Campus, No.156 Beiqing Road 297 Hai-Dian District, Beijing, 100095 298 P.R. China 300 Email: duzongpeng@huawei.com 302 Sheng Jiang 303 Huawei Technologies Co., Ltd 304 Q14, Huawei Campus, No.156 Beiqing Road 305 Hai-Dian District, Beijing, 100095 306 P.R. China 308 Email: jiangsheng@huawei.com