idnits 2.17.1 draft-ietf-anima-stable-connectivity-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 5, 2018) is 2272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-13 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-09 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-05 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA T. Eckert, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational M. Behringer 5 Expires: August 9, 2018 February 5, 2018 7 Using Autonomic Control Plane for Stable Connectivity of Network OAM 8 draft-ietf-anima-stable-connectivity-10 10 Abstract 12 OAM (Operations, Administration and Maintenance - as per BCP161, 13 (RFC6291) processes for data networks are often subject to the 14 problem of circular dependencies when relying on connectivity 15 provided by the network to be managed for the OAM purposes. 17 Provisioning while bringing up devices and networks tends to be more 18 difficult to automate than service provisioning later on, changes in 19 core network functions impacting reachability cannot be automated 20 because of ongoing connectivity requirements for the OAM equipment 21 itself, and widely used OAM protocols are not secure enough to be 22 carried across the network without security concerns. 24 This document describes how to integrate OAM processes with an 25 autonomic control plane in order to provide stable and secure 26 connectivity for those OAM processes. This connectivity is not 27 subject to aforementioned circular dependencies. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 9, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Self-dependent OAM Connectivity . . . . . . . . . . . . . 3 65 1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3 66 1.3. Leveraging a generalized autonomic control plane . . . . 4 67 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Stable Connectivity for Centralized OAM . . . . . . . . . 5 69 2.1.1. Simple Connectivity for Non-GACP capable NMS Hosts . 6 70 2.1.2. Challenges and Limitation of Simple Connectivity . . 7 71 2.1.3. Simultaneous GACP and data-plane Connectivity . . . . 8 72 2.1.4. IPv4-only NMS Hosts . . . . . . . . . . . . . . . . . 9 73 2.1.5. Path Selection Policies . . . . . . . . . . . . . . . 12 74 2.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 15 75 2.1.7. Encryption of data-plane connections . . . . . . . . 15 76 2.1.8. Long Term Direction of the Solution . . . . . . . . . 16 77 2.2. Stable Connectivity for Distributed Network/OAM . . . . . 17 78 3. Architectural Considerations . . . . . . . . . . . . . . . . 17 79 3.1. No IPv4 for GACP . . . . . . . . . . . . . . . . . . . . 17 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 83 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 20 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 86 8.2. Informative References . . . . . . . . . . . . . . . . . 24 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 89 1. Introduction 90 1.1. Self-dependent OAM Connectivity 92 OAM (Operations, Administration and Maintenance - as per BCP161, 93 [RFC6291]) for data networks is often subject to the problem of 94 circular dependencies when relying on the connectivity service 95 provided by the network to be managed. OAM can easily but 96 unintentionally break the connectivity required for its own 97 operations. Avoiding these problems can lead to complexity in OAM. 98 This document describes this problem and how to use an autonomic 99 control plane to solve it without further OAM complexity: 101 The ability to perform OAM on a network device requires first the 102 execution of OAM necessary to create network connectivity to that 103 device in all intervening devices. This typically leads to 104 sequential, 'expanding ring configuration' from a NOC (Network 105 Operations Center). It also leads to tight dependencies between 106 provisioning tools and security enrollment of devices. Any process 107 that wants to enroll multiple devices along a newly deployed network 108 topology needs to tightly interlock with the provisioning process 109 that creates connectivity before the enrollment can move on to the 110 next device. 112 When performing change operations on a network, it likewise is 113 necessary to understand at any step of that process that there is no 114 interruption of connectivity that could lead to removal of 115 connectivity to remote devices. This includes especially change 116 provisioning of routing, forwarding, security and addressing policies 117 in the network that often occur through mergers and acquisitions, the 118 introduction of IPv6 or other mayor re-hauls in the infrastructure 119 design. Examples include change of an IGP or areas, PA (Provider 120 Aggregatable) to PI (Provider Independent) addressing, or systematic 121 topology changes (such as L2 to L3 changes). 123 All these circular dependencies make OAM complex and potentially 124 fragile. When automation is being used, for example through 125 provisioning systems, this complexity extends into that automation 126 software. 128 1.2. Data Communication Networks (DCNs) 130 In the late 1990s and early 2000, IP networks became the method of 131 choice to build separate OAM networks for the communications 132 infrastructure within Network Providers. This concept was 133 standardized in ITU-T G.7712/Y.1703 [ITUT] and called "Data 134 Communications Networks" (DCN). These were (and still are) 135 physically separate IP(/MPLS) networks that provide access to OAM 136 interfaces of all equipment that had to be managed, from PSTN (Public 137 Switched Telephone Network) switches over optical equipment to 138 nowadays Ethernet and IP/MPLS production network equipment. 140 Such DCN provide stable connectivity not subject to aforementioned 141 problems because they are a separate network entirely, so change 142 configuration of the production IP network is done via the DCN but 143 never affects the DCN configuration. Of course, this approach comes 144 at a cost of buying and operating a separate network and this cost is 145 not feasible for many providers, most notably smaller providers, most 146 enterprises and typical IoT networks (Internet of Things). 148 1.3. Leveraging a generalized autonomic control plane 150 One of the goals of the IETF ANIMA (Autonomic Networking Integrated 151 Model and Approach ) working group is the specification of a secure 152 and automatically built inband management plane that provides similar 153 stable connectivity as a DCN, but without having to build a separate 154 DCN. It is clear that such 'in-band' approach can never achieve 155 fully the same level of separation, but the goal is to get as close 156 to it as possible. 158 This goal of this document is to discuss how such an inband 159 management plane can be used to support the DCN-like OAM use-case, 160 leverage its stable connectivity and details the options of deploying 161 it incrementally - short and long term. 163 The evolving ANIMA working groups specification 164 [I-D.ietf-anima-autonomic-control-plane] ) calls this inband 165 management plane the "Autonomic Control Plane" (ACP). The 166 discussions in this document are not depending on the specification 167 of that ACP, but only on a set of high level constraints decided 168 early on in the work for the ACP. Unless being specific about 169 details of the ACP, this document uses the term "Generalized ACP" 170 (GACP) and is applicable to any designs that meet those high level 171 constraints. For example - but not limited to - variations of the 172 ACP protocol choices. 174 The high level constraints of a GACP assumed and discussed in this 175 document are as follows: 177 VRF Isolation: The GACP is a virtual network ("VRF") across network 178 devices - its routing and forwarding are separate from other 179 routing and forwarding in the network devices. Non-GACP routing/ 180 forwarding is called the "data-plane". 182 IPv6 only addressing: The GACP provides only IPv6 reachability. It 183 uses ULA addresses ([RFC4193]) that are routed in a location 184 independent fashion for example through per network device subnet 185 prefixes. Automatic addressing in the GACP is therefore simple & 186 stable: it does not require allocation by address registries, 187 addresses are identifiers, they do not change when devices move, 188 and no engineering of the address space to the network topology is 189 necessary. 191 NOC connectivity: NOC equipment (controlling OAM operations) either 192 has access to the GACP directly or has an IP subnet connection to 193 a GACP-edge device. 195 Closed Group Security: GACP devices have cryptographic credentials 196 to mutually authenticate each other as members of a GACP. Traffic 197 across the GACP is authenticated with these credentials and then 198 encrypted. The only traffic permitted in & out of the GACP that 199 is not authenticated by these credentials is through explicit 200 configuration the traffic from/to the aforementioned non-GACP NOC 201 equipment with subnet connections to a GACP-edge device (as a 202 transition method). 204 The GACP must be built autonomic and its function must not be 205 disruptable by operator or automated (NMS/SDN) configuration/ 206 provisioning actions. These are allowed to only impact the "data- 207 plane". This aspect is not currently covered in this document. 208 Instead, it focusses on the impact of the above constraints: IPv6 209 only, dual connectivity and security. 211 2. Solutions 213 2.1. Stable Connectivity for Centralized OAM 215 The ANI is the "Autonomic Networking Infrastructure" consisting of 216 secure zero touch Bootstrap (BRSKI - 217 [I-D.ietf-anima-bootstrapping-keyinfra]), GeneRic Autonomic Signaling 218 Protocol (GRASP - [I-D.ietf-anima-grasp]), and Autonomic Control 219 Plane (ACP - [I-D.ietf-anima-autonomic-control-plane]). Refer to 220 [I-D.ietf-anima-reference-model] for an overview of the ANI and how 221 its components interact and [RFC7575] for concepts and terminology of 222 ANI and autonomic networks. 224 This section describes stable connectivity for centralized OAM via 225 the GACP, for example via the ACP with or without a complete ANI, 226 starting by what we expect to be the most easy to deploy short-term 227 option. It then describes limitation and challenges of that approach 228 and their solutions/workarounds to finish with the preferred target 229 option of autonomic NOC devices in Section 2.1.6. 231 This order was chosen because it helps to explain how simple initial 232 use of a GACP can be, how difficult workarounds can become (and 233 therefore what to avoid), and finally because one very promising 234 long-term solution alternative is exactly like the most easy short- 235 term solution only virtualized and automated. 237 In the most common case, OAM will be performed by one or more 238 applications running on a variety of centralized NOC systems that 239 communicate with network devices. We describe differently advanced 240 approaches to leverage a GACP for stable connectivity. There is a 241 wide range of options, some of which are simple, some more complex. 243 Three stages can be considered: 245 o There are simple options described in sections Section 2.1.1 246 through Section 2.1.3 that we consider to be good starting points 247 to operationalize the use of a GACP for stable connectivity today. 248 These options require only network and OAN/NOC device 249 configuration. 251 o The are workarounds to connect a GACP to non-IPv6 capable NOC 252 devices through the use of IPv4/IPv6 NAT (Network Address 253 Translation) as described in section Section 2.1.4. These 254 workarounds are not recommended but if such non-IPv6 capable NOC 255 devices need to be used longer term, then this is the only option 256 to connect them to a GACP. 258 o Near to long term options can provide all the desired operational, 259 zero touch and security benefits of an autonomic network, but a 260 range of details for this still have to be worked out and 261 development work on NOC/OAM equipment is necessary. These options 262 are discussed in sections Section 2.1.5 through Section 2.1.8. 264 2.1.1. Simple Connectivity for Non-GACP capable NMS Hosts 266 In the most simple candidate deployment case, the GACP extends all 267 the way into the NOC via one or more "GACP-edge-devices". See also 268 section 6.1 of [I-D.ietf-anima-autonomic-control-plane]. These 269 devices "leak" the (otherwise encrypted) GACP natively to NMS hosts. 270 They act as the default routers to those NMS hosts and provide them 271 with IPv6 connectivity into the GACP. NMS hosts with this setup need 272 to support IPv6 (see e.g. [RFC6434]) but require no other 273 modifications to leverage the GACP. 275 Note that even though the GACP only uses IPv6, it can of course 276 support OAM for any type of network deployment as long as the network 277 devices support the GACP: The data-plane can be IPv4 only, dual-stack 278 or IPv6 only. It is always separate from the GACP, therefore there 279 is no dependency between the GACP and the IP version(s) used in the 280 data-plane. 282 This setup is sufficient for troubleshooting such as SSH into network 283 devices, NMS that performs SNMP read operations for status checking, 284 software downloads into autonomic devices, provisioning of devices 285 via NETCONF and so on. In conjunction with otherwise unmodified OAM 286 via separate NMS hosts it can provide a good subset of the stable 287 connectivity goals. The limitations of this approach are discussed 288 in the next section. 290 Because the GACP provides 'only' for IPv6 connectivity, and because 291 addressing provided by the GACP does not include any topological 292 addressing structure that operations in a NOC often relies on to 293 recognize where devices are on the network, it is likely highly 294 desirable to set up DNS (Domain Name System - see [RFC1034]) so that 295 the GACP IPv6 addresses of autonomic devices are known via domain 296 names that include the desired structure. For example, if DNS in the 297 network was set up with names for network devices as 298 devicename.noc.example.com, and the well-known structure of the data- 299 plane IPv4 addresses space was used by operators to infer the region 300 where a device is located in, then the GACP address of that device 301 could be set up as devicename_.acp.noc.example.com, and 302 devicename.acp.noc.example.com could be a CNAME to 303 devicename_.acp.noc.example.com. Note that many networks 304 already use names for network equipment where topological information 305 is included, even without a GACP. 307 2.1.2. Challenges and Limitation of Simple Connectivity 309 This simple connectivity of non-autonomic NMS hosts suffers from a 310 range of challenges (that is, operators may not be able to do it this 311 way) or limitations (that is, operator cannot achieve desired goals 312 with this setup). The following list summarizes these challenges and 313 limitations. The following sections describe additional mechanisms 314 to overcome them. 316 Note that these challenges and limitations exist because GACP is 317 primarily designed to support distributed ASA (Autonomic Service 318 Agent, a piece of autonomic software) in the most lightweight 319 fashion, but not mandatorily require support for additional 320 mechanisms to best support centralized NOC operations. It is this 321 document that describes additional (short term) workarounds and (long 322 term) extensions. 324 1. (Limitation) NMS hosts cannot directly probe whether the desired 325 so called 'data-plane' network connectivity works because they do 326 not directly have access to it. This problem is similar to 327 probing connectivity for other services (such as VPN services) 328 that they do not have direct access to, so the NOC may already 329 employ appropriate mechanisms to deal with this issue (probing 330 proxies). See Section 2.1.3 for candidate solutions. 332 2. (Challenge) NMS hosts need to support IPv6 which often is still 333 not possible in enterprise networks. See Section 2.1.4 for some 334 workarounds. 336 3. (Limitation) Performance of the GACP may be limited versus normal 337 'data-plane' connectivity. The setup of the GACP will often 338 support only non-hardware accelerated forwarding. Running a 339 large amount of traffic through the GACP, especially for tasks 340 where it is not necessary will reduce its performance/ 341 effectiveness for those operations where it is necessary or 342 highly desirable. See Section 2.1.5 for candidate solutions. 344 4. (Limitation) Security of the GACP is reduced by exposing the GACP 345 natively (and unencrypted) into a subnet in the NOC where the NOC 346 devices are attached to it. See Section 2.1.7 for candidate 347 solutions. 349 These four problems can be tackled independently of each other by 350 solution improvements. Combining some of these solutions 351 improvements together can lead towards a candidate long term 352 solution. 354 2.1.3. Simultaneous GACP and data-plane Connectivity 356 Simultaneous connectivity to both GACP and data-plane can be achieved 357 in a variety of ways. If the data-plane is IPv4-only, then any 358 method for dual-stack attachment of the NOC device/application will 359 suffice: IPv6 connectivity from the NOC provides access via the GACP, 360 IPv4 will provide access via the data-plane. If as explained above 361 in the simple case, an autonomic device supports native attachment to 362 the GACP, and the existing NOC setup is IPv4 only, then it could be 363 sufficient to attach the GACP device(s) as the IPv6 default router to 364 the NOC subnet and keep the existing IPv4 default router setup 365 unchanged. 367 If the data-plane of the network is also supporting IPv6, then the 368 most compatible setup for NOC devices is to have two IPv6 interfaces. 369 One virtual ((e.g. via IEEE 802.1Q [IEEE802.1Q]) or physical 370 interface connecting to a data-plane subnet, and another into an GACP 371 connect subnet. See section 8.1 of 372 [I-D.ietf-anima-autonomic-control-plane] for more details. That 373 document also specifies how the NOC devices can receive auto 374 configured addressing and routes towards the ACP connect subnet if it 375 supports [RFC6724] and [RFC4191]. 377 Configuring a second interface on a NOC host may be impossible or be 378 seen as undesired complexity. In that case the GACP edge device 379 needs to provide support for a "Combined ACP and data-plane 380 interface" as also described in section 8.1 of 381 [I-D.ietf-anima-autonomic-control-plane]. This setup may not work 382 with auto configuration and all NOC host network stacks due to 383 limitations in those network stacks. They need to be able to perform 384 RFC6724 source address selection rule 5.5 including caching of next- 385 hop information. 387 For security reasons, it is not considered appropriate to connect a 388 non-GACP router to a GACP connect interface. The reason is that the 389 GACP is a secured network domain and all NOC devices connecting via 390 GACP connect interfaces are also part of that secure domain - the 391 main difference is that the physical link between the GACP edge 392 device and the NOC devices is not authenticated/encrypted and 393 therefore, needs to be physically secured. If the secure GACP was 394 extendable via untrusted routers then it would be a lot more 395 difficult to verify the secure domain assertion. Therefore the GACP 396 edge devices are not supposed to redistribute routes from non-GACP 397 routers into the GACP. 399 2.1.4. IPv4-only NMS Hosts 401 One architectural expectation for the GACP as described in 402 Section 1.3 is that all devices that want to use the GACP do support 403 IPv6. Including NMS hosts. Note that this expectation does not 404 imply any requirements against the data-plane, especially no need to 405 support IPv6 in it. The data-plane could be IPv4 only, IPv6 only, 406 dual stack or it may not need to have any IP host stack on the 407 network devices. 409 The implication of this architectural decision is the potential need 410 for short-term workarounds when the operational practices in a 411 network do not yet meet these target expectations. This section 412 explains when and why these workarounds may be operationally 413 necessary and describes them. However, the long term goal is to 414 upgrade all NMS hosts to native IPv6, so the workarounds described in 415 this section should not be considered permanent. 417 Most network equipment today supports IPv6 but it is by far not 418 ubiquitously supported in NOC backend solutions (HW/SW), especially 419 not in the product space for enterprises. Even when it is supported, 420 there are often additional limitations or issues using it in a dual 421 stack setup or the operator mandates for simplicity single stack for 422 all operations. For these reasons an IPv4 only management plane is 423 still required and common practice in many enterprises. Without the 424 desire to leverage the GACP, this required and common practice is not 425 a problem for those enterprises even when they run dual stack in the 426 network. We discuss these workarounds here because it is a short 427 term deployment challenge specific to the operations of a GACP. 429 To connect IPv4 only management plane devices/applications with a 430 GACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is 431 necessary. The basic mechanisms for this are defined in SIIT 432 ([RFC7915]). There are multiple solutions using this mechanism. To 433 understand the possible solutions, we consider the requirements: 435 1. NMS hosts need to be able to initiate connections to any GACP 436 device for management purposes. Examples include provisioning 437 via Netconf/(SSH), SNMP poll operations or just diagnostics via 438 SSH connections from operators. Every GACP device/function that 439 needs to be reachable from NMS hosts needs to have a separate 440 IPv4 address. 442 2. GACP devices need to be able to initiate connections to NMS hosts 443 for example to initiate NTP or radius/diameter connections, send 444 syslog or SNMP trap or initiate Netconf Call Home connections 445 after bootstrap. Every NMS host needs to have a separate IPv6 446 address reachable from the GACP. When connections from GACP 447 devices are made to NMS hosts, the IPv4 source address of these 448 connections as seen by the NMS Host must also be unique per GACP 449 device and the same address as in (1) to maintain the same 450 addressing simplicity as in a native IPv4 deployment. For 451 example in syslog, the source-IP address of a logging device is 452 used to identify it, and if the device shows problems, an 453 operator might want to SSH into the device to diagnose it. 455 Because of these requirements, the necessary and sufficient set of 456 solutions are those that provide 1:1 mapping of IPv6 GACP addresses 457 into IPv4 space and 1:1 mapping of IPv4 NMS host space into IPv6 (for 458 use in the GACP). This means that stateless SIIT based solutions are 459 sufficient and preferred. 461 Note that GACP devices may use multiple IPv6 addresses in the GACP. 462 For example, [I-D.ietf-anima-autonomic-control-plane] section 6.10 463 defines multiple useful addressing sub-schemes supporting this 464 option. All those addresses may then need to be reachable through 465 the IPv6/IPv4 address translation. 467 The need to allocate for every GACP device one or multiple IPv4 468 addresses should not be a problem if - as we assume - the NMS hosts 469 can use private IPv4 address space ([RFC1918]). Nevertheless even 470 with RFC1918 address space it is important that the GACP IPv6 471 addresses can efficiently be mapped into IPv4 address space without 472 too much waste. 474 The currently most flexible mapping scheme to achieve this is 475 [RFC7757] because it allows configured IPv4 <-> IPv6 prefix mapping. 476 Assume the GACP uses the ACP "Zone Addressing" Sub-Scheme and there 477 are 3 registrars. In the Zone Addressing Sub-Scheme, there is for 478 each registrar a constant /112 prefix for which in RFC7757 an EAM 479 (Explicit Address Mapping) into a /16 (e.g.: RFC1918) prefix into 480 IPv4 can be configured. Within the registrars /112 prefix, Device- 481 Numbers for devices are sequentially assigned: with V-bit effectively 482 two numbers are assigned per GACP device. This also means that if 483 IPv4 address space is even more constrained, and it is known that a 484 registrar will never need the full /15 extent of Device-Numbers, then 485 a longer than /112 prefix can be configured into the EAM to use less 486 IPv4 space. 488 When using the ACP "Vlong Addressing" Sub-Scheme, it is unlikely that 489 one wants or need to translate the full /8 or /16 bits of addressing 490 space per GACP device into IPv4. In this case, the EAM rules of 491 dropping trailing bits can be used to map only N bits of the V-bits 492 into IPv4. This does imply though that only V-addresses that differ 493 in those high-order N V-bits can be distinguished on the IPv4 side. 495 Likewise, the IPv4 address space used for NMS hosts can easily be 496 mapped into an address prefix assigned to a GACP connect interface. 498 A full specification of a solution to perform SIIT in conjunction 499 with GACP connect following the considerations below is outside the 500 scope of this document. 502 To be in compliance with security expectations, SIIT has to happen on 503 the GACP edge device itself so that GACP security considerations can 504 be taken into account. E.g.: that IPv4 only NMS hosts can be dealt 505 with exactly like IPv6 hosts connected to a GACP connect interface. 507 Note that prior solutions such as NAT64 ([RFC6146]) may equally be 508 useable to translate between GACP IPv6 address space and NMS Hosts 509 IPv4 address space, and that as workarounds this can also be done on 510 non GACP Edge Devices connected to a GACP connect interface. The 511 details vary depending on implementation because the options to 512 configure address mappings vary widely. Outside of EAM, there are no 513 standardized solutions that allow for mapping of prefixes, so it will 514 most likely be necessary to explicitly map every individual (/128) 515 GACP device address to an IPv4 address. Such an approach should use 516 automation/scripting where these address translation entries are 517 created dynamically whenever a GACP device is enrolled or first 518 connected to the GACP network. 520 Overall, the use of NAT is especially subject to the ROI (Return On 521 Investment) considerations, but the methods described here may not be 522 too different from the same problems encountered totally independent 523 of GACP when some parts of the network are to introduce IPv6 but NMS 524 hosts are not (yet) upgradeable. 526 2.1.5. Path Selection Policies 528 As mentioned above, a GACP is not expected to have high performance 529 because its primary goal is connectivity and security, and for 530 existing network device platforms this often means that it is a lot 531 more effort to implement that additional connectivity with hardware 532 acceleration than without - especially because of the desire to 533 support full encryption across the GACP to achieve the desired 534 security. 536 Some of these issues may go away in the future with further adoption 537 of a GACP and network device designs that better tender to the needs 538 of a separate OAM plane, but it is wise to plan for even long-term 539 designs of the solution that does NOT depend on high-performance of 540 the GACP. This is opposite to the expectation that future NMS hosts 541 will have IPv6, so that any considerations for IPv4/NAT in this 542 solution are temporary. 544 To solve the expected performance limitations of the GACP, we do 545 expect to have the above describe dual-connectivity via both GACP and 546 data-plane between NOC application devices and devices with GACP. 547 The GACP connectivity is expected to always be there (as soon as a 548 device is enrolled), but the data-plane connectivity is only present 549 under normal operations but will not be present during e.g. early 550 stages of device bootstrap, failures, provisioning mistakes or during 551 network configuration changes. 553 The desired policy is therefore as follows: In the absence of further 554 security considerations (see below), traffic between NMS hosts and 555 GACP devices should prefer data-plane connectivity and resort only to 556 using the GACP when necessary, unless it is an operation known to be 557 so much tied to the cases where the GACP is necessary that it makes 558 no sense to try using the data-plane. An example are SSH connections 559 from the NOC into a network device to troubleshoot network 560 connectivity. This could easily always rely on the GACP. Likewise, 561 if an NMS host is known to transmit large amounts of data, and it 562 uses the GACP, then its performance need to be controlled so that it 563 will not overload the GACP performance. Typical examples of this are 564 software downloads. 566 There is a wide range of methods to build up these policies. We 567 describe a few: 569 Ideally, a NOC system would learn and keep track of all addresses of 570 a device (GACP and the various data-plane addresses). Every action 571 of the NOC system would indicate via a "path-policy" what type of 572 connection it needs (e.g. only data-plane, GACP-only, default to 573 data-plane, fallback to GACP,...). A connection policy manager would 574 then build connection to the target using the right address(es). 575 Shorter term, a common practice is to identify different paths to a 576 device via different names (e.g. loopback vs. interface addresses). 577 This approach can be expanded to GACP uses, whether it uses NOC 578 system local names or DNS. We describe example schemes using DNS: 580 DNS can be used to set up names for the same network devices but with 581 different addresses assigned: One name (name.noc.example.com) with 582 only the data-plane address(es) (IPv4 and/or IPv6) to be used for 583 probing connectivity or performing routine software downloads that 584 may stall/fail when there are connectivity issues. One name (name- 585 acp.noc.example.com) with only the GACP reachable address of the 586 device for troubleshooting and probing/discovery that is desired to 587 always only use the GACP. One name with data-plane and GACP 588 addresses (name-both.noc.example.com). 590 Traffic policing and/or shaping at the GACP edge in the NOC can be 591 used to throttle applications such as software download into the 592 GACP. 594 Using different names mapping to different (subset of) addresses can 595 be difficult to set up and maintain, especially also because data- 596 plane addresses may change due to reconfiguration or relocation of 597 devices. The name based approach alone can also not well support 598 policies for existing applications and long-lived flows to 599 automatically switch between ACP and data-plane in the face of data- 600 plane failure and recovery. A solution would be GACP node host 601 transport stacks supporting the following requirements: 603 1. Only the GACP addresses of the responder must be required by the 604 initiator for the initial setup of a connection/flow across the 605 GACP. 607 2. Responder and Initiator must be able to exchange their data-plane 608 addresses through the GACP, and then - if needed by policy - 609 build an additional flow across the data-plane. 611 3. For unmodified application, the following policies should be 612 configurable on at least a per-application basis for its TCP 613 connections with GACP peers: 615 Fallback (to GACP): An additional data-plane flow is built and 616 used exclusively to send data whenever the data-plane is 617 operational. When it can not be built during connection setup 618 or when it fails later, traffic is sent across the GACP flow. 619 This could be a default-policy for most OAM applications using 620 the GACP. 622 >Suspend/Fail: Like the Fallback policy, except that traffic 623 will not use the GACP flow but will be suspended until a data- 624 plane flow is operational or until a policy configurable 625 timeout indicates a connection failure to the application. 626 This policy would be appropriate for large volume background/ 627 scavenger class OAM application/connections such as firmware 628 downloads or telemetry/diagnostic uploads - which would 629 otherwise easily overrun performance limited GACP 630 implementations. 632 >GACP (only): No additional data-plane flow is built, traffic is 633 only sent via the GACP flow. This can just be a TCP 634 connection. This policy would be most appropriate for OAM 635 operations known to change the data plane in a way that could 636 impact (at least temporarily) connectivity through it. 638 4. In the presence of responders or initiators not supporting these 639 host stack functions, the Fallback and GACP policies must result 640 in a TCP connection across the GACP. For Suspend/Fail, presence 641 of TCP-only peers should result in failure during connection 642 setup. 644 5. In case of Fallback and Suspend/Fail, a failed data-plane 645 connection should automatically be rebuilt when the data-plane 646 recovers, including the case that the data-plane address of one 647 (or both) side(s) may have changed - for example because of 648 reconfiguration or device repositioning. 650 6. Additional data-plane flows created by these host transport stack 651 functions must be end-to-end authenticated by it with the GACP 652 domain credentials and encrypted. This maintains the expectation 653 that connections from GACP addresses to GACP addresses are 654 authenticated/encrypted. This may be skipped if the application 655 already provides for end-to-end encryption. 657 7. For enhanced applications, the host stack may support application 658 control to select the policy on a per-connection basis, or even 659 more explicit control for building of the flows and which flow 660 should pass traffic. 662 Protocols like MPTCP (Multipath TCP -see [RFC6824]) and SCTP 663 ([RFC4960]) can already support part of these requirements. MPTCP 664 for example supports signaling of addresses in a TCP backward 665 compatible fashion, establishment of additional flows (called 666 subflows in MPTCP) and having primary and fallback subflows via 667 MP_PRIO signalling. The details if or how MPTCP, SCTP and/or other 668 approaches potentially with extensions and/or (shim) layers on top of 669 them can best provide a complete solution for the above requirements 670 is subject to further work outside the scope of this document. 672 2.1.6. Autonomic NOC Device/Applications 674 Setting up connectivity between the NOC and autonomic devices when 675 the NOC device itself is non-autonomic is as mentioned in the 676 beginning a security issue. It also results as shown in the previous 677 paragraphs in a range of connectivity considerations, some of which 678 may be quite undesirable or complex to operationalize. 680 Making NMS hosts autonomic and having them participate in the GACP is 681 therefore not only a highly desirable solution to the security 682 issues, but can also provide a likely easier operationalization of 683 the GACP because it minimizes NOC-special edge considerations - the 684 GACP is simply built all the way automatically, even inside the NOC 685 and only authorized and authenticate NOC devices/applications will 686 have access to it. 688 Supporting the ACP according to 689 [I-D.ietf-anima-autonomic-control-plane] all the way into an 690 application device requires implementing the following aspects in it: 691 AN bootstrap/enrollment mechanisms, the secure channel for the ACP 692 and at least the host side of IPv6 routing setup for the ACP. 693 Minimally this could all be implemented as an application and be made 694 available to the host OS via e.g. a tap driver to make the ACP show 695 up as another IPv6 enabled interface. 697 Having said this: If the structure of NMS hosts is transformed 698 through virtualization anyhow, then it may be considered equally 699 secure and appropriate to construct (physical) NMS host system by 700 combining a virtual GACP enabled router with non-GACP enabled NOC- 701 application VMs via a hypervisor, leveraging the configuration 702 options described in the previous sections but just virtualizing 703 them. 705 2.1.7. Encryption of data-plane connections 707 When combining GACP and data-plane connectivity for availability and 708 performance reasons, this too has an impact on security: When using 709 the GACP, the traffic will be mostly encryption protected, especially 710 when considering the above described use of application devices with 711 GACP. If instead the data-plane is used, then this is not the case 712 anymore unless it is done by the application. 714 The simplest solution for this problem exists when using GACP capable 715 NMS hosts, because in that case the communicating GACP capable NMS 716 host and the GACP network device have credentials they can mutually 717 trust (same GACP domain). In result, data-plane connectivity that 718 does support this can simply leverage TLS/DTLS 719 ([RFC5246])/([RFC6347]) with those GACP credentials for mutual 720 authentication - and does not incur new key management. 722 If this automatic security benefit is seen as most important, but a 723 "full" GACP stack into the NMS host is unfeasible, then it would 724 still be possible to design a stripped down version of GACP 725 functionality for such NOC hosts that only provides enrollment of the 726 NOC host with the GACP cryptographic credentials but without directly 727 participating in the GACP encryption method. Instead, the host would 728 just leverage TLS/DTLS using its GACP credentials via the data-plane 729 with GACP network devices as well as indirectly via the GACP with the 730 above mentioned GACP connect into the GACP. 732 When using the GACP itself, TLS/DTLS for the transport layer between 733 NMS hosts and network device is somewhat of a double price to pay 734 (GACP also encrypts) and could potentially be optimized away, but 735 given the assumed lower performance of the GACP, it seems that this 736 is an unnecessary optimization. 738 2.1.8. Long Term Direction of the Solution 740 If we consider what potentially could be the most lightweight and 741 autonomic long term solution based on the technologies described 742 above, we see the following direction: 744 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the 745 network to enable use of a GACP is long term undesirable. Having 746 IPv4 only applications automatically leverage IPv6 connectivity 747 via host-stack translation may be an option but this has not been 748 investigated yet. 750 2. Build the GACP as a lightweight application for NMS hosts so GACP 751 extends all the way into the actual NMS hosts. 753 3. Leverage and as necessary enhance host transport stacks with 754 automatic multipath-connectivity GACP and data-plane as outlined 755 in Section 2.1.5. 757 4. Consider how to best map NMS host desires to underlying transport 758 mechanisms: With the above mentioned 3 points, not all options 759 are covered. Depending on the OAM, one may still want only GACP, 760 only data-plane, or automatically prefer one over the other and/ 761 or use the GACP with low performance or high-performance (for 762 emergency OAM such as countering DDoS). It is as of today not 763 clear what the simplest set of tools is to enable explicitly the 764 choice of desired behavior of each OAM. The use of the above 765 mentioned DNS and multipath mechanisms is a start, but this will 766 require additional work. This is likely a specific case of the 767 more generic scope of TAPS. 769 2.2. Stable Connectivity for Distributed Network/OAM 771 Today, many distributed protocols implement their own unique security 772 mechanisms. 774 KARP (Keying and Authentication for Routing Protocols, see [RFC6518]) 775 has tried to start to provide common directions and therefore reduce 776 the re-invention of at least some of the security aspects, but it 777 only covers routing-protocols and it is unclear how well it is 778 applicable to a potentially wider range of network distributed agents 779 such as those performing distributed OAM. The common security of a 780 GACP can help in these cases. 782 Furthermore, GRASP ([I-D.ietf-anima-grasp]) can run on top of a GACP 783 as a security and transport substrate and provide common local & 784 remote neighbor discovery and peer negotiation mechanism, further 785 allowing to unifying & reuse future protocol designs. 787 3. Architectural Considerations 789 3.1. No IPv4 for GACP 791 The GACP is intended to be IPv6 only, and the prior explanations in 792 this document show that this can lead to some complexity when having 793 to connect IPv4 only NOC solutions, and that it will be impossible to 794 leverage the GACP when the OAM agents on a GACP network device do not 795 support IPv6. Therefore, the question was raised whether the GACP 796 should optionally also support IPv4. 798 The decision not to include IPv4 for GACP as something that is 799 considered in the use cases in this document is because of the 800 following reasons: 802 In SP networks that have started to support IPv6, often the next 803 planned step is to consider moving out IPv4 from a native transport 804 to just a service on the edge. There is no benefit/need for multiple 805 parallel transport families within the network, and standardizing on 806 one reduces OPEX and improves reliability. This evolution in the 807 data-plane makes it highly unlikely that investing development cycles 808 into IPv4 support for GACP will have a longer term benefit or enough 809 critical short-term use-cases. Support for IPv6-only for GACP is 810 purely a strategic choice to focus on the known important long term 811 goals. 813 In other types of networks as well, we think that efforts to support 814 autonomic networking is better spent in ensuring that one address 815 family will be supported so all use cases will long-term work with 816 it, instead of duplicating effort into IPv4. Especially because 817 auto-addressing for the GACP with IPv4 would be more complex than in 818 IPv6 due to the IPv4 addressing space. 820 4. Security Considerations 822 In this section, we discuss only security considerations not covered 823 in the appropriate sub-sections of the solutions described. 825 Even though GACPs are meant to be isolated, explicit operator 826 misconfiguration to connect to insecure OAM equipment and/or bugs in 827 GACP devices may cause leakage into places where it is not expected. 828 Mergers/Acquisitions and other complex network reconfigurations 829 affecting the NOC are typical examples. 831 GACP addresses are ULA addresses. Using these addresses also for NOC 832 devices as proposed in this document is not only necessary for above 833 explained simple routing functionality but it is also more secure 834 than global IPv6 addresses. ULA addresses are not routed in the 835 global Internet and will therefore be subject to more filtering even 836 in places where specific ULA addresses are being used. Packets are 837 therefore less likely to leak to be successfully injected into the 838 isolated GACP environment. 840 The random nature of a ULA prefix provides strong protection against 841 address collision even though there is no central assignment 842 authority. This is helped by the expectation that GACPs are never 843 expected to connect all together, but only few GACPs may ever need to 844 connect together, e.g. when mergers and acquisitions occur. 846 Note that the GACP constraints demands that only packets from 847 connected subnet prefixes are permitted from GACP connect interfaces, 848 limiting the scope of non-cryptographically secured transport to a 849 subnet within a NOC that instead has to rely on physical security 850 (only connect trusted NOC devices to it). 852 To help diagnose packets that unexpectedly leaked for example from 853 another GACP (that was meant to be deployed separately), it can be 854 useful to voluntarily list your own the ULA GACP prefixes on some 855 site(s) on the Internet and hope that other users of GACPs do the 856 same so that you can look up unknown ULA prefix packets seen in your 857 network. Note that this does not constitute registration. 859 https://www.sixxs.net/tools/grh/ula/ was a site to list ULA prefixes 860 but it is not open for new listings anymore since the mid of 2017. 861 The authors are not aware of other active Internet sites to list ULA 862 use. 864 Note that there is a provision in [RFC4193] for non-locally assigned 865 address space (L bit = 0), but there is no existing standardization 866 for this, so these ULA prefixes must not be used. 868 According to [RFC4193] section 4.4, PTR records for ULA addresses 869 should not be installed into the global DNS (no guaranteed 870 ownership). Hence also the need to rely on voluntary lists (and in 871 prior paragraph) to make the use of an ULA prefix globally known. 873 Nevertheless, some legacy OAM applications running across the GACP 874 may rely on reverse DNS lookup for authentication of requests (e.g.: 875 TFTP for download of network firmware/config/software). Operators 876 may therefore need to use a private DNS setup for the GACP ULA 877 addresses. This is the same setup that would be necessary for using 878 RFC1918 addresses in DNS. See for example [RFC1918] section 5, last 879 paragraph. In [RFC6950] section 4, these setups are discussed in 880 more detail. 882 Any current and future protocols must rely on secure end-to-end 883 communications (TLS/DTLS) and identification and authentication via 884 the certificates assigned to both ends. This is enabled by the 885 cryptographic credentials mechanisms of the GACP. 887 If DNS and especially reverse DNS are set up, then it should be set 888 up in an automated fashion when the GACP address for devices are 889 assigned. In the case of the ACP, DNS resource record creation can 890 be linked to the autonomic registrar backend so that the DNS and 891 reverse DNS records are actually derived from the subject name 892 elements of the ACP device certificates in the same way as the 893 autonomic devices themselves will derive their ULA addresses from 894 their certificates to ensure correct and consistent DNS entries. 896 If an operator feels that reverse DNS records are beneficial to its 897 own operations but that they should not be made available publically 898 for "security" by concealment reasons, then the case of GACP DNS 899 entries is probably one of the least problematic use cases for split- 900 DNS: The GACP DNS names are only needed for the NMS hosts intending 901 to use the GACP - but not network wide across the enterprise. 903 5. IANA Considerations 905 This document requests no action by IANA. 907 6. Acknowledgements 909 This work originated from an Autonomic Networking project at cisco 910 Systems, which started in early 2010 including customers involved in 911 the design and early testing. Many people contributed to the aspects 912 described in this document, including in alphabetical order: BL 913 Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, Ravi 914 Kumar Vadapalli. The author would also like to thank Michael 915 Richardson, James Woodyatt and Brian Carpenter for their review and 916 comments. Special thanks to Sheng Jiang and Mohamed Boucadair for 917 their thorough review. 919 7. Change log [RFC Editor: Please remove] 921 10: Added paragraph to multipath text to better summarize the 922 reason why to do this. 924 10: Mirja: reworded multipath text to remove instructive 925 description how the desired functionality would map to MPTCP 926 features, extensions or shim layers. Describe the desired 927 functionality now only as requirements. Expert WGs including but 928 not limited to MPTCP and future documents need to define best 929 design/spec option. 931 10: BrianC: Added requirement to 'MPTCP' section for end-to-end 932 encryption across data plane when connection is via GACP. 934 09: Mirja/Yoshifumi: reworded MPTCP policy rule examples, 935 stack->endpoint (agnostic to where policy is implemented). 937 08: IESG review fixes. 939 * Spell check. 941 * https://raw.githubusercontent.com/anima-wg/autonomic-control- 942 plane/01908364cfc7259009603bf2b261354b0cc26913/draft-ietf- 943 anima-stable-connectivity/draft-ietf-anima-stable-connectivity- 944 08.txt 946 * Eric Rescorla (comments):Typos, listing ULA on internet 947 benefits. Other comments from Eric where addressed via commits 948 for other reviewers already. 950 * https://raw.githubusercontent.com/anima-wg/autonomic-control- 951 plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf- 952 anima-stable-connectivity/draft-ietf-anima-stable-connectivity- 953 08.txt 955 * Mirja Kuehlewind (discuss) / Yoshifumi Nishida: Fixed and 956 Rewrote MPTCP text to be more explanatory, answering questions 957 raised in disucss. 959 * https://raw.githubusercontent.com/anima-wg/autonomic-control- 960 plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf- 961 anima-stable-connectivity/draft-ietf-anima-stable-connectivity- 962 08.txt 964 * Matthew Miller/Alissa Cooper: syntactic nits. 966 * https://raw.githubusercontent.com/anima-wg/autonomic-control- 967 plane/9bff109281e8b3c22522c3144cbf0f13e5000498/draft-ietf- 968 anima-stable-connectivity/draft-ietf-anima-stable-connectivity- 969 08.txt 971 * Suresh Krishnan (comment): rewrote first paragraph of 2.1.4 972 (incomprehensible). 974 * https://raw.githubusercontent.com/anima-wg/autonomic-control- 975 plane/f2d8a85c2cc65ca7f823abac0f57d19c744f9b65/draft-ietf- 976 anima-stable-connectivity/draft-ietf-anima-stable-connectivity- 977 08.txt 979 * Alvaro Retana: Made references normative where the authors 980 think is is important to understand all or parts for the 981 mechanisms described in this document. 983 * Alvaro Retana: Clarified that the discussions in this document 984 are not specific to the ANI ACP, but instead rely primarily on 985 a set of design constraints for any type of autonomic inband 986 management network. Called this the GACP (generalized ACP). 987 Mayor add: explanation of those design constraints in section 988 1.3. Textual fixes ACP -> GACP throughout the document, but 989 without semantic changes. 991 * https://raw.githubusercontent.com/anima-wg/autonomic-control- 992 plane/d26df831da2953779c3b3ac41ec118cbbe43373e/draft-ietf- 993 anima-stable-connectivity/draft-ietf-anima-stable-connectivity- 994 08.txt 996 * Co-author organization fix. 998 07: Fixed ID nits. 1000 06: changed "split-horizon" term to "private-DNS" and reworded the 1001 paragraph about it. 1003 05: Integrated fixes from Brian Carpenters review. See github 1004 draft-ietf-anima-stable-connectivity/04-brian-carpenter-review- 1005 reply.txt. Details on semantic/structural changes: 1007 * Folded most comments back into draft-ietf-anima-autonomic- 1008 control-plane-09 because this stable connectivity draft was 1009 suggesting things that are better written out and standardized 1010 in the ACP document. 1012 * Section on simultaneous ACP and data-plane connectivity section 1013 reduced/rewritten because of this. 1015 * Re-emphasized security model of ACP - ACP-connect can not 1016 arbitrarily extend ACP routing domain. 1018 * Re-wrote much of NMS section to be less suggestive and more 1019 descriptive, avoiding the term NAT and referring to relevant 1020 RFCs (SIIT etc.). 1022 * Main additional text in IPv4 section is about explaining how we 1023 suggest to use EAM (Explicit Address Mapping) which actuall 1024 would well work with the Zone and Vlong Addressing Sub-Schemes 1025 of ACP. 1027 * Moved, but not changed section of "why no IPv4 in ACP" before 1028 IANA considerations to make structure of document more logical. 1030 * Refined security considerations: explained how optional ULA 1031 prefix listing on Internet is only for diagnostic purposes. 1032 Explained how this is useful because DNS must not be used. 1033 Explained how split horizon DNS can be used nevertheless. 1035 04: Integrated fixes from Mohamed Boucadairs review (thorough 1036 textual review). 1038 03: Integrated fixes from thorough Shepherd review (Sheng Jiang). 1040 01: Refresh timeout. Stable document, change in author 1041 association. 1043 01: Refresh timeout. Stable document, no changes. 1045 00: Changed title/dates. 1047 individual-02: Updated references. 1049 individual-03: Modified ULA text to not suggest ULA-C as much 1050 better anymore, but still mention it. 1052 individual-02: Added explanation why no IPv4 for ACP. 1054 individual-01: Added security section discussing the role of 1055 address prefix selection and DNS for ACP. Title change to 1056 emphasize focus on OAM. Expanded abstract. 1058 individual-00: Initial version. 1060 8. References 1062 8.1. Normative References 1064 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1065 and E. Lear, "Address Allocation for Private Internets", 1066 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1067 . 1069 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1070 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1071 November 2005, . 1073 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1074 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1075 . 1077 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1078 "Default Address Selection for Internet Protocol Version 6 1079 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1080 . 1082 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1083 "TCP Extensions for Multipath Operation with Multiple 1084 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1085 . 1087 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1088 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1089 Networking: Definitions and Design Goals", RFC 7575, 1090 DOI 10.17487/RFC7575, June 2015, 1091 . 1093 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 1094 Mappings for Stateless IP/ICMP Translation", RFC 7757, 1095 DOI 10.17487/RFC7757, February 2016, 1096 . 1098 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1099 "IP/ICMP Translation Algorithm", RFC 7915, 1100 DOI 10.17487/RFC7915, June 2016, 1101 . 1103 8.2. Informative References 1105 [I-D.ietf-anima-autonomic-control-plane] 1106 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1107 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1108 plane-13 (work in progress), December 2017. 1110 [I-D.ietf-anima-bootstrapping-keyinfra] 1111 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1112 S., and K. Watsen, "Bootstrapping Remote Secure Key 1113 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1114 keyinfra-09 (work in progress), October 2017. 1116 [I-D.ietf-anima-grasp] 1117 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1118 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1119 grasp-15 (work in progress), July 2017. 1121 [I-D.ietf-anima-reference-model] 1122 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 1123 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 1124 Reference Model for Autonomic Networking", draft-ietf- 1125 anima-reference-model-05 (work in progress), October 2017. 1127 [IEEE802.1Q] 1128 International Telecommunication Union, "802.1Q-2014 - IEEE 1129 Standard for Local and metropolitan area networks - 1130 Bridges and Bridged Networks", 2014. 1132 [ITUT] International Telecommunication Union, "Architecture and 1133 specification of data communication network", 1134 ITU-T Recommendation G.7712/Y.1703, Noevember 2001. 1136 This is the earliest but superceeded version of the 1137 series. See "https://www.itu.int/rec/T-REC-G.7712/en" for 1138 current versions. 1140 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1141 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1142 . 1144 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1145 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1146 . 1148 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1149 (TLS) Protocol Version 1.2", RFC 5246, 1150 DOI 10.17487/RFC5246, August 2008, 1151 . 1153 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1154 NAT64: Network Address and Protocol Translation from IPv6 1155 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1156 April 2011, . 1158 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 1159 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 1160 Acronym in the IETF", BCP 161, RFC 6291, 1161 DOI 10.17487/RFC6291, June 2011, 1162 . 1164 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1165 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1166 January 2012, . 1168 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1169 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 1170 2011, . 1172 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 1173 Routing Protocols (KARP) Design Guidelines", RFC 6518, 1174 DOI 10.17487/RFC6518, February 2012, 1175 . 1177 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 1178 "Architectural Considerations on Application Features in 1179 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 1180 . 1182 Authors' Addresses 1183 Toerless Eckert (editor) 1184 Futurewei Technologies Inc. 1185 2330 Central Expy 1186 Santa Clara 95050 1187 USA 1189 Email: tte+ietf@cs.fau.de 1191 Michael H. Behringer 1193 Email: michael.h.behringer@gmail.com