idnits 2.17.1 draft-ietf-anima-stable-connectivity-02.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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2017) is 2635 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.behringer-anima-reference-model' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-autonomic-control-plane' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-bootstrapping-keyinfra' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-an-gap-analysis' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-autonomic-network-definitions' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 720, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-05 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-04 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA T. Eckert 3 Internet-Draft Huawei 4 Intended status: Informational M. Behringer 5 Expires: August 11, 2017 Cisco 6 February 7, 2017 8 Using Autonomic Control Plane for Stable Connectivity of Network OAM 9 draft-ietf-anima-stable-connectivity-02 11 Abstract 13 OAM (Operations, Administration and Management) processes for data 14 networks are often subject to the problem of circular dependencies 15 when relying on network connectivity of the network to be managed for 16 the OAM operations itself. Provisioning during device/network bring 17 up tends to be far less easy to automate than service provisioning 18 later on, changes in core network functions impacting reachability 19 can not be automated either because of ongoing connectivity 20 requirements for the OAM equipment itself, and widely used OAM 21 protocols are not secure enough to be carried across the network 22 without security concerns. 24 This document describes how to integrate OAM processes with the 25 autonomic control plane (ACP) in Autonomic Networks (AN). to provide 26 stable and secure connectivity for those OAM processes. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 11, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Self dependent OAM connectivity . . . . . . . . . . . . . 3 64 1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3 65 1.3. Leveraging the ACP . . . . . . . . . . . . . . . . . . . 4 66 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Stable connectivity for centralized OAM operations . . . 4 68 2.1.1. Simple connectivity for non-autonomic NOC application 69 devices . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1.2. Limitations and enhancement overview . . . . . . . . 5 71 2.1.3. Simultaneous ACP and data plane connectivity . . . . 6 72 2.1.4. IPv4 only NOC application devices . . . . . . . . . . 7 73 2.1.5. Path selection policies . . . . . . . . . . . . . . . 8 74 2.1.6. Autonomic NOC device/applications . . . . . . . . . . 10 75 2.1.7. Encryption of data-plane connections . . . . . . . . 10 76 2.1.8. Long term direction of the solution . . . . . . . . . 11 77 2.2. Stable connectivity for distributed network/OAM functions 12 78 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 4. No IPv4 for ACP . . . . . . . . . . . . . . . . . . . . . . . 14 80 5. Further considerations . . . . . . . . . . . . . . . . . . . 14 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 83 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 15 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 88 1.1. Self dependent OAM connectivity 90 OAM (Operations, Administration and Management) processes for data 91 networks are often subject to the problem of circular dependencies 92 when relying on network connectivity of the network to be managed for 93 the OAM operations itself: 95 The ability to perform OAM operations on a network device requires 96 first the execution of OAM procedures necessary to create network 97 connectivity to that device in all intervening devices. This 98 typically leads to sequential, 'expanding ring configuration' from a 99 NOC. It also leads to tight dependencies between provisioning tools 100 and security enrollment of devices. Any process that wants to enroll 101 multiple devices along a newly deployed network topology needs to 102 tightly interlock with the provisioning process that creates 103 connectivity before the enrollment can move on to the next device. 105 When performing change operations on a network, it likewise is 106 necessary to understand at any step of that process that there is no 107 interruption of connectivity that could lead to removal of 108 connectivity to remote devices. This includes especially change 109 provisioning of routing, security and addressing policies in the 110 network that often occur through mergers and acquisitions, the 111 introduction of IPv6 or other mayor re-hauls in the infrastructure 112 design. 114 All this circular dependencies make OAM processes complex and 115 potentially fragile. When automation is being used, for example 116 through provisioning systems or network controllers, this complexity 117 extends into that automation software. 119 1.2. Data Communication Networks (DCNs) 121 In the late 1990'th and early 2000, IP networks became the method of 122 choice to build separate OAM networks for the communications 123 infrastructure in service providers. This concept was standardized 124 in G.7712/Y.1703 and called "Data Communications Networks" (DCN). 125 These where (and still are) physically separate IP(/MPLS) networks 126 that provide access to OAM interfaces of all equipment that had to be 127 managed, from PSTN switches over optical equipment to nowadays 128 ethernet and IP/MPLS production network equipment. 130 Such DCN provide stable connectivity not subject to aforementioned 131 problems because they are separate network entirely, so change 132 configuration of the production IP network is done via the DCN but 133 never affects the DCN configuration. Of course, this approach comes 134 at a cost of buying and operating a separate network and this cost is 135 not feasible for many networks, most notably smaller service 136 providers, most enterprises and typical IoT networks. 138 1.3. Leveraging the ACP 140 One goal of the Autonomic Networks Autonomic Control plane (ACP) is 141 to provide similar stable connectivity as a DCN, but without having 142 to build a separate DCN. It is clear that such 'in-band' approach 143 can never achieve fully the same level of separation, but the goal is 144 to get as close to it as possible. 146 This solution approach has several aspects. One aspect is designing 147 the implementation of the ACP in network devices to make it actually 148 perform without interruption by changes in what we will call in this 149 document the "data-plane", aka: the operator or controller configured 150 services planes of the network equipment. This aspect is not 151 currently covered in this document. 153 Another aspect is how to leverage the stable IPv6 connectivity 154 provided by the ACP to build actual OAM solutions. This is the 155 current scope of this document. 157 2. Solutions 159 2.1. Stable connectivity for centralized OAM operations 161 In the most common case, OAM operations will be performed by one or 162 more applications running on a variety of centralized NOC systems 163 that communicate with network devices. We describe differently 164 advanced approaches to leverage the ACP for stable connectivity 165 leveraging the ACP. The descriptions will show that there is a wide 166 range of options, some of which are simple, some more complex. 168 Most easily we think there are three stages of interest: 170 o There are simple options described first that we consider to be 171 good starting points to operationalize the use of the ACP for 172 stable connectivity. 174 o The are more advanced intermediate options that try to establish 175 backward compatibility with existing deployed approached such as 176 leveraging NAT. Selection and deployment of these approaches 177 needs to be carefully vetted to ensure that they provide positive 178 RoI. This very much depends on the operational processes of the 179 network operator. 181 o It seems clearly feasible to build towards a long-term 182 configuration that provides all the desired operational, zero 183 touch and security benefits of an autonomic network, but a range 184 of details for this still have to be worked out. 186 2.1.1. Simple connectivity for non-autonomic NOC application devices 188 In the most simple deployment case, the ACP extends all the way into 189 the NOC via a network device that is set up to provide access into 190 the ACP natively to non-autonomic devices. It acts as the default- 191 router to those hosts and provides them with only IPv6 connectivity 192 into the ACP - but no IPv4 connectivity. NOC devices with this setup 193 need to support IPv6 but require no other modifications to leverage 194 the ACP. 196 This setup is sufficient for troubleshooting OAM operations such as 197 SSH into network devices, NMS that perform SNMP read operations for 198 status checking, for software downloads into autonomic devices and so 199 on. In conjunction with otherwise unmodified OAM operations via 200 separate NOC devices/applications it can provide a good subset of the 201 interesting stable connectivity goals from the ACP. 203 Because the ACP provides 'only' for IPv6 connectivity, and because 204 the addressing provided by the ACP does not include any addressing 205 structure that operations in a NOC often relies on to recognize where 206 devices are on the network, it is likely highly desirable to set up 207 DNS so that the ACP IPv6 addresses of autonomic devices are known via 208 domain names with logical names. For example, if DNS in the network 209 was set up with names for network devices as 210 devicename.noc.example.com, then the ACP address of that device could 211 be mapped to devicename-acp.noc.exmaple.com. 213 2.1.2. Limitations and enhancement overview 215 This most simple type of attachment of NOC applications to the ACP 216 suffers from a range of limitations: 218 1. NOC applications can not directly probe whether the desired so 219 called 'data-plane' network connectivity works because they do 220 not directly have access to it. This problem is not dissimilar 221 to probing connectivity for other services (such as VPN services) 222 that they do not have direct access to, so the NOC may already 223 employ appropriate mechanisms to deal with this issue (probing 224 proxies). 226 2. NOC applications need to support IPv6 which often is still not 227 the case in many enterprise networks. 229 3. Performance of the ACP will be limited versus normal 'data-plane' 230 connectivity. The setup of the ACP will often support only non- 231 hardware accelerated forwarding. Running a large amount of 232 traffic through the ACP, especially for tasks where it is not 233 necessary will reduce its performance/effectiveness for those 234 operations where it is necessary or highly desirable. 236 4. Security of the ACP is reduced by exposing the ACP natively (and 237 unprotected) into a LAN In the NOC where the NOC devices are 238 attached to it. 240 These four problems can be tackled independently of each other by 241 solution improvements. Combining these solutions improvements 242 together ultimately leads towards the the target long term solution. 244 2.1.3. Simultaneous ACP and data plane connectivity 246 Simultaneous connectivity to both ACP and data-plane can be achieved 247 in a variety of ways. If the data-plane is only IPv4, then any 248 method for dual-stack attachment of the NOC device/application will 249 suffice: IPv6 connectivity from the NOC provides access via the ACP, 250 IPv4 will provide access via the data-plane. If as explained above 251 in the most simple case, an autonomic device supports native 252 attachment to the ACP, and the existing NOC setup is IPv4 only, then 253 it could be sufficient to simply attach the ACP device(s) as the IPv6 254 default-router to the NOC LANs and keep the existing IPv4 default 255 router setup unchanged. 257 If the data-plane of the network is also supporting IPv6, then the 258 NOC devices that need access to the ACP should have a dual-homing 259 IPv6 setup. One option is to make the NOC devices multi-homed with 260 one logical or physical IPv6 interface connecting to the data-plane, 261 and another into the ACP. The LAN that provides access to the ACP 262 should then be given an IPv6 prefix that shares a common prefix with 263 the IPv6 ULA of the ACP so that the standard IPv6 interface selection 264 rules on the NOC host would result in the desired automatic selection 265 of the right interface: towards the ACP facing interface for 266 connections to ACP addresses, and towards the data-plane interface 267 for anything else. If this can not be achieved automatically, then 268 it needs to be done via simple IPv6 static routes in the NOC host. 270 Providing two virtual (eg: dot1q subnet) connections into NOC hosts 271 may be seen as undesired complexity. In that case the routing policy 272 to provide access to both ACP and data-plane via IPv6 needs to happen 273 in the NOC network itself: The NOC application device gets a single 274 attachment interface but still with the same two IPv6 addresses as in 275 before - one for use towards the ACP, one towards the data-plane. 276 The first-hop router connecting to the NOC application device would 277 then have separate interfaces: one towards the data-plane, one 278 towards the ACP. Routing of traffic from NOC application hosts would 279 then have to be based on the source IPv6 address of the host: Traffic 280 from the address designated for ACP use would get routed towards the 281 ACP, traffic from the designated data-plane address towards the data- 282 plane. 284 In the most simple case, we get the following topology: Existing NOC 285 application devices connect via an existing NOClan and existing first 286 hop Rtr1 to the data-plane. Rtr1 is not made autonomic, but instead 287 the edge router of the Autonomic network ANrtr is attached via a 288 separate interface to Rtr1 and ANrtr provides access to the ACP via 289 ACPaccessLan. Rtr1 is configured with the above described IPv6 290 source routing policies and the NOC-app-devices are given the 291 secondary IPv6 address for connectivity into the ACP. 293 --... (data-plane) 294 NOC-app-device(s) -- NOClan -- Rtr1 295 --- ACPaccessLan -- ANrtr ... (ACP) 297 Figure 1 299 If Rtr1 was to be upgraded to also implement Autonomic Networking and 300 the ACP, the picture would change as follows: 302 ---- ... (data-plane) 303 NOC-app-device(s) ---- NOClan --- ANrtr1 304 . . ---- ... (ACP) 305 \-/ 306 (ACP to data-plane loopback) 308 Figure 2 310 In this case, ANrtr1 would have to implement some more advanced 311 routing such as cross-VRF routing because the data-plane and ACP are 312 most likely run via separate VRFs. A simple short-term workaround 313 could be a physical external loopback cable into two ports of ANrtr1 314 to connect the data-plane and ACP VRF as shown in the picture. 316 2.1.4. IPv4 only NOC application devices 318 With the ACP being intentionally IPv6 only, attachment of IPv4 only 319 NOC application devices to the ACP requires the use of IPv4 to IPv6 320 NAT. This NAT setup could for example be done in Rt1r1 in above 321 picture to also support IPv4 only NOC application devices connected 322 to NOClan. 324 To support connections initiated from IPv4 only NOC applications 325 towards the ACP of network devices, it is necessary to create a 326 static mapping of ACP IPv6 addresses into an unused IPv4 address 327 space and dynamic or static mapping of the IPv4 NOC application 328 device address (prefix) into IPv6 routed in the ACP. The main issue 329 in this setup is the mapping of all ACP IPv6 addresses to IPv4. 330 Without further network intelligence, this needs to be a 1:1 address 331 mapping because the prefix used for ACP IPv6 addresses is too long to 332 be mapped directly into IPv4 on a prefix basis. 334 One could implement in router software dynamic mappings by leveraging 335 DNS, but it seems highly undesirable to implement such complex 336 technologies for something that ultimately is a temporary problem 337 (IPv4 only NOC application devices). With today's operational 338 directions it is likely more preferable to automate the setup of 1:1 339 NAT mappings in that NAT router as part of the automation process of 340 network device enrollment into the ACP. 342 The ACP can also be used for connections initiated by the network 343 device into the NOC application devices. For example syslog from 344 autonomic devices. In this case, static mappings of the NOC 345 application devices IPv4 addresses are required. This can easily be 346 done with a static prefix mapping into IPv6. 348 Overall, the use of NAT is especially subject to the RoI 349 considerations, but the methods described here may not be too 350 different from the same problems encountered totally independent of 351 AN/ACP when some parts of the network are to introduce IPv6 but NOC 352 application devices are not (yet) upgradeable. 354 2.1.5. Path selection policies 356 As mentioned above, the ACP is not expected to have high performance 357 because its primary goal is connectivity and security, and for 358 existing networ device platforms this often means that it is a lot 359 more effort to implement that additional connectivity with hardware 360 acceleration than without - especially because of the desire to 361 support full encryption across the ACP to achieve the desired 362 security. 364 Some of these issues may go away in the future with further adoption 365 of the ACP and network device designs that better tender to the needs 366 of a separate OAM plane, but it is wise to plan for even long-term 367 designs of the solution that does NOT depend on high-performance of 368 the ACP. This is opposite to the expectation that future NOC 369 application devices will have IPv6, so that any considerations for 370 IPv4/NAT in this solution are temporary. 372 To solve the expected performance limitations of the ACP, we do 373 expect to have the above describe dual-connectivity via both ACP and 374 data-plane between NOC application devices and AN devices with ACP. 375 The ACP connectivity is expected to always be there (as soon as a 376 device is enrolled), but the data-plane connectivity is only present 377 under normal operations but will not be present during eg: early 378 stages of device bootstrap, failures, provisioning mistakes or during 379 network configuration changes. 381 The desired policy is therefore as follows: In the absence of further 382 security considerations (see below), traffic between NOC application 383 and AN devices should prefer data-plane connectivity and resort only 384 to using the ACP when necessary, unless it is an operation known to 385 be so much tied to the cases where the ACP is necessary that it makes 386 no sense to try using the data plane. An example here is of course 387 the SSH connection from the NOC into a network device to troubleshoot 388 network connectivity. This could easily always rely on the ACP. 389 Likewise, if a NOC application is known to transmit large amounts of 390 data, and it uses the ACP, then its performance need to be controlled 391 so that it will not overload the ACP performance. Typical examples 392 of this are software downloads. 394 There is a wide range of methods to build up these policies. We 395 describe a few: 397 DNS can be used to set up names for the same network devices but with 398 different addresses assigned: One name (name.noc.example.com) with 399 only the data-plane address(es) (IPv4 and/or IPv6) to be used for 400 probing connectivity or performing routine software downloads that 401 may stall/fail when there are connectivity issues. One name (name- 402 acp.noc.example.com) with only the ACP reachable address of the 403 device for troubleshooting and probing/discovery that is desired to 404 always only use the ACP. One name with data plane and ACP addresses 405 (name-both.noc.example.com). 407 Traffic policing and/or shaping of at the ACP edge in the NOC can be 408 used to throttle applications such as software download into the ACP. 410 MP-TCP is a very attractive candidate to automate the use of both 411 data-plane and ACP and minimize or fully avoid the need for the above 412 mentioned logical names to pre-set the desired connectivity (data- 413 plane-only, ACP only, both). For example, a set-up for non MP-TCP 414 aware applications would be as follows: 416 DNS naming is set up to provide the ACP IPv6 address of network 417 devices. Unbeknownst to the application, MP-TCP is used. MP-TCP 418 mutually discovers between the NOC and network device the data-plane 419 address and caries all traffic across it when that MP-TCP sub-flow 420 across the data-plane can be built. 422 In the Autonomic network devices where data-plane and ACP are in 423 separate VRFs, it is clear that this type of MP-TCP sub-flow creation 424 across different VRFs is new/added functionality. Likewise the 425 policies of preferring a particular address (NOC-device) or VRF (AN 426 device) for the traffic is potentially also a policy not provided as 427 a standard. 429 2.1.6. Autonomic NOC device/applications 431 Setting up connectivity between the NOC and autonomic devices when 432 the NOC device itself is non-autonomic is as mentioned in the 433 beginning a security issue. It also results as shown in the previous 434 paragraphs in a range of connectivity considerations, some of which 435 may be quite undesirable or complex to operationalize. 437 Making NOC application devices autonomic and having them participate 438 in the ACP is therefore not only a highly desirable solution to the 439 security issues, but can also provide a likely easier 440 operationalization of the ACP because it minimizes NOC-special edge 441 considerations - the ACP is simply built all the way automatically, 442 even inside the NOC and only authorized and authenticate NOC devices/ 443 applications will have access to it. 445 Supporting the ACP all the way into an application device requires 446 implementing the following aspects in it: AN bootstrap/enrollment 447 mechanisms, the secure channel for the ACP and at least the host side 448 of IPv6 routing setup for the ACP. Minimally this could all be 449 implemented as an application and be made available to the host OS 450 via eg: a tap driver to make the ACP show up as another IPv6 enabled 451 interface. 453 Having said this: If the structure of NOC applications is transformed 454 through virtualization anyhow, then it may be considered equally 455 secure and appropriate to construct a (physical) NOC application 456 system by combining a virtual AN/ACP enabled router with non-AN/ACP 457 enabled NOC-application VMs via a hypervisor, leveraging the 458 configuration options described in the previous sections but jut 459 virtualizing them. 461 2.1.7. Encryption of data-plane connections 463 When combining ACP and data-plane connectivity for availability and 464 performance reasons, this too has an impact on security: When using 465 the ACP, the traffic will be mostly encryption protected, especially 466 when considering the above described use of AN application devices. 468 If instead the data-plane is used, then this is not the case anymore 469 unless it is done by the application. 471 The most simple solution for this problem exists when using AN NOC 472 application devices, because in that case the communicating AN NOC 473 application and the AN network device have certificates through the 474 AN enrollment process that they can mutually trust (same AN domain). 475 In result, data-plane connectivity that does support this can simply 476 leverage TLS/dTLS with mutual AN-domain certificate authentication - 477 and does not incur new key management. 479 If this automatic security benefit is seen as most important, but a 480 "full" ACP stack into the NOC application device is unfeasible, then 481 it would still be possible to design a stripped down version of AN 482 functionality for such NOC hosts that only provides enrollment of the 483 NOC host into the AN domain to the extend that the host receives an 484 AN domain certificate, but without directly participating in the ACP 485 afterwards. Instead, the host would just leverage TLS/dTLS using its 486 AN certificate via the data-plane with AN network devices as well as 487 indirectly via the ACP with the above mentioned in-NOC network edge 488 connectivity into the ACP. 490 When using the ACP itself, TLS/dTLS for the transport layer between 491 NOC application and network device is somewhat of a double price to 492 pay (ACP also encrypts) and could potentially be optimized away, but 493 given the assumed lower performance of the ACP, it seems that this is 494 an unnecessary optimization. 496 2.1.8. Long term direction of the solution 498 If we consider what potentially could be the most lightweight and 499 autonomic long term solution based on the technologies described 500 above, we see the following direction: 502 1. NOC applications should at least support IPv6. IPv4/IPv6 NAT in 503 the network to enable use of ACP is long term undesirable. 504 Having IPv4 only applications automatically leverage IPv6 505 connectivity via host-stack options is likely non-feasible (NOTE: 506 this has still to be vetted more). 508 2. Build the ACP as a lightweight application for NOC application 509 devices so ACP extends all the way into the actual NOC 510 application devices. 512 3. Leverage and as necessary enhance MP-TCP with automatic dual- 513 connectivity: If the MP-TCP unaware application is using ACP 514 connectivity, the policies used should add sub-flow(s) via the 515 data-plane and prefer them. 517 4. Consider how to best map NOC application desires to underlying 518 transport mechanisms: With the above mentioned 3 points, not all 519 options are covered. Depending on the OAM operation, one may 520 still want only ACP, only data-plane, or automatically prefer one 521 over the other and/or use the ACP with low performance or high- 522 performance (for emergency OAM actions such as countering DDoS). 523 It is as of today not clear what the simplest set of tools is to 524 enable explicitly the choice of desired behavior of each OAM 525 operations. The use of the above mentioned DNS and MP-TCP 526 mechanisms is a start, but this will require additional thoughts. 527 This is likely a specific case of the more generic scope of TAPS. 529 2.2. Stable connectivity for distributed network/OAM functions 531 The ACP can provide common direct-neighbor discovery and capability 532 negotiation and stable and secure connectivity for functions running 533 distributed in network devices. It can therefore eliminate the need 534 to re-implement similar functions in each distributed function in the 535 network. Today, every distributed protocol does this with functional 536 elements usually called "Hello" mechanisms and with often protocol 537 specific security mechanisms. 539 KARP has tried to start provide common directions and therefore 540 reduce the re-invention of at least some of the security aspects, but 541 it only covers routing-protocols and it is unclear how well it 542 applicable to a potentially wider range of network distributed agents 543 such as those performing distributed OAM functions. The ACP can help 544 in these cases. 546 This section is TBD for further iterations of this draft. 548 3. Security Considerations 550 We discuss only security considerations not covered in the 551 appropriate sub-sections of the solutions described. 553 Even though ACPs are meant to be isolated, explicit operator 554 misconfiguration to connect to insecure OAM equipment and/or bugs in 555 ACP devices may cause leakage into places where it is not expected. 556 Mergers/Aquisitions and other complex network reconfigurations 557 affecting the NOC are typical examples. 559 ULA addressing as proposed in this document is preferred over 560 globally reachable addresses because it is not routed in the global 561 Internet and will therefore be subject to more filtering even in 562 places where specific ULA addresses are being used. 564 Randomn ULA addressing provides more than sufficient protection 565 against address collision even though there is no central assignment 566 authority. This is helped by the expectation, that ACPs are never 567 expected to connect all together, but only few ACPs may ever need to 568 connect together, eg: when mergers and aquisitions occur. 570 If packets with unexpected ULA addresses are seen and one expects 571 them to be from another networks ACP from which they leaked, then 572 some form of ULA prefix registrastion (not allocation) can be 573 beneficial. Some voluntary registries exist, for example 574 https://www.sixxs.net/tools/grh/ula/, although none of them is 575 preferrable because of being operated by some recognized authority. 576 If an operator would want to make its ULA prefix known, it might need 577 to register it with multiple existing registries. 579 ULA Centrally assigned ULA addresses (ULA-C) was an attempt to 580 introduce centralized registration of randomnly assigned addresses 581 and potentially even carve out a different ULA prefix for such 582 addresses. This proposal is currently not proceeding, and it is 583 questionable whether the stable connectivity use case provides 584 sufficient motivation to revive this effort. 586 Using current registration options implies that there will not be 587 reverse DNS mapping for ACP addresses. For that one will have to 588 rely on looking up the unknown/unexpected network prefix in the 589 registry registry to determine the owner of these addresses. 591 Reverse DNS resolution may be beneficial for specific already 592 deployed insecure legacy protocols on NOC OAM systems that intend to 593 communicate via the ACP (eg: TFTP) and leverages reverse-DNS for 594 authentication. Given how the ACP provides path security except 595 potentially for the last-hop in the NOC, the ACP does make it easier 596 to extend the lifespan of such protocols in a secure fashion as far 597 to just the transport is concerned. The ACP does not make reverse 598 DNS lookup a secure authentication method though. Any current and 599 future protocols must rely on secure end-to-end communications (TLD, 600 dTLS) and identification and authentication via the certificates 601 assigned to both ends. This is enabled by the certificate mechanisms 602 of the ACP. 604 If DNS and especially reverse DNS are set up, then it should be set 605 up in an automated fashion, linked to the autonomic registrar backend 606 so that the DNS and reverse DNS records are actually derived from the 607 subject name elements of the ACP device certificates in the same way 608 as the autonomic devices themselves will derive their ULA addresses 609 from their certificates to ensure correct and consistent DNS entries. 611 If an operator feels that reverse DNS records are beneficial to its 612 own operations but that they should not be made available publically 613 for "security" by concealment reasons, then the case of ACP DNS 614 entries is probably one of the least problematic use cases for split- 615 DNS: The ACP DNS names are only needed for the NOC applications 616 intending to use the ACP - but not network wide across the 617 enterprise. 619 4. No IPv4 for ACP 621 The ACP is targeted to be IPv6 only, and the prior explanations in 622 this document show that this can lead to some complexity when having 623 to connect IPv4 only NOC solutions, and that it will be impossible to 624 leverage the ACP when the OAM agents on an ACP network device do not 625 support IPv6. Therefore, the question was raised whether the ACP 626 should optionally also support IPv4. 628 The decision not to include IPv4 for ACP as something that is 629 considered in the use cases in this document is because of the 630 following reasons: 632 In SP networks that have started to support IPv6, often the next 633 planned step is to consider moving out IPv4 from a native transport 634 as just a service on the edge. There is no benefit/need for multiple 635 parallel transport families within the network, and standardizing on 636 one reduces OPEX and improves reliability. This evolution in the 637 data plane makes it highly unlikely that investing development cycles 638 into IPv4 support for ACP will have a longer term benefit or enough 639 critical short-term use-cases. Support for only IPv4 for ACP is 640 purely a strategic choice to focus on the known important long term 641 goals. 643 In other type of networks as well, we think that efforts to support 644 autonomic networking is better spent in ensuring that one address 645 family will be support so all use cases will long-term work with it, 646 instead of duplicating effort into IPv4. Especially because auto- 647 addressing for the ACP with IPv4 would be more ecomplex than in IPv6 648 due to the the IPv4 addressing space. 650 5. Further considerations 652 6. IANA Considerations 654 This document requests no action by IANA. 656 7. Acknowledgements 658 This work originated from an Autonomic Networking project at cisco 659 Systems, which started in early 2010 including customers involved in 660 the design and early testing. Many people contributed to the aspects 661 described in this document, including in alphabetical order: BL 662 Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, Ravi 663 Kumar Vadapalli. The author would also like to thank Michael 664 Richardson, James Woodyatt and Brian Carpenter for their review and 665 comments. 667 8. Change log [RFC Editor: Please remove] 669 01: Refresh timeout. Stable document, change in author 670 association. 672 01: Refresh timeout. Stable document, no changes. 674 00: Changed title/dates. 676 individual-02: Updated references. 678 individual-03: Modified ULA text to not suggest ULA-C as much 679 better anymore, but still mention it. 681 individual-02: Added explanation why no IPv4 for ACP. 683 individual-01: Added security section discussing the role of 684 address prefix selection and DNS for ACP. Title change to 685 emphasize focus on OAM. Expanded abstract. 687 individual-00: Initial version. 689 9. References 691 [I-D.behringer-anima-reference-model] 692 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 693 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 694 for Autonomic Networking", draft-behringer-anima- 695 reference-model-04 (work in progress), October 2015. 697 [I-D.ietf-anima-autonomic-control-plane] 698 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 699 Control Plane", draft-ietf-anima-autonomic-control- 700 plane-05 (work in progress), January 2017. 702 [I-D.ietf-anima-bootstrapping-keyinfra] 703 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 704 S., and K. Watsen, "Bootstrapping Remote Secure Key 705 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 706 keyinfra-04 (work in progress), October 2016. 708 [I-D.irtf-nmrg-an-gap-analysis] 709 Jiang, S., Carpenter, B., and M. Behringer, "General Gap 710 Analysis for Autonomic Networking", draft-irtf-nmrg-an- 711 gap-analysis-06 (work in progress), April 2015. 713 [I-D.irtf-nmrg-autonomic-network-definitions] 714 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 715 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 716 Networking - Definitions and Design Goals", draft-irtf- 717 nmrg-autonomic-network-definitions-07 (work in progress), 718 March 2015. 720 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 721 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 722 . 724 Authors' Addresses 726 Toerless Eckert 727 Futurewei Technologies Inc. 728 2330 Central Expy 729 Santa Clara 95050 730 USA 732 Email: tte+ietf@cs.fau.de 734 Michael H. Behringer 735 Cisco 737 Email: mbehring@cisco.com