idnits 2.17.1 draft-irtf-nmrg-an-gap-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (April 2, 2014) is 3677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-farrelll-mpls-opportunistic-encrypt-02 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-00 == Outdated reference: A later version (-02) exists of draft-jiang-config-negotiation-protocol-00 == Outdated reference: A later version (-03) exists of draft-jiang-config-negotiation-ps-02 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force M. Behringer 3 Internet-Draft Cisco Systems 4 Intended status: Informational B. Carpenter 5 Expires: October 4, 2014 Univ. of Auckland 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 April 2, 2014 10 Gap Analysis for Autonomic Networking 11 draft-irtf-nmrg-an-gap-analysis-00 13 Abstract 15 This document summarises a problem statement for an IP-based 16 autonomic network that is mainly based on distributed network 17 devices. The document reviews the history and current status of 18 autonomic aspects of IP networks. It then reviews the current 19 network management style, which is still heavily depending on human 20 administrators. Finally the document describes the general gaps 21 between the ideal autonomic network concept and the current network 22 abilities. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 4, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Current Status of Autonomic Aspects of IP Networks . . . . . 3 61 3.1. IP Address Management and DNS . . . . . . . . . . . . . . 3 62 3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Configuration of Default Router . . . . . . . . . . . . . 5 64 3.4. Hostname Lookup . . . . . . . . . . . . . . . . . . . . . 5 65 3.5. User Authentication and Accounting . . . . . . . . . . . 5 66 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.7. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Current Non-Autonomic Behaviors . . . . . . . . . . . . . . . 7 69 4.1. Network Establishment . . . . . . . . . . . . . . . . . . 7 70 4.2. Network Maintenance & Management . . . . . . . . . . . . 7 71 4.3. Troubleshooting and Recovery . . . . . . . . . . . . . . 8 72 5. Approach toward Autonomy . . . . . . . . . . . . . . . . . . 9 73 5.1. More Coordination among Devices or Network Partitions . . 9 74 5.2. Forecasting and Dry Runs . . . . . . . . . . . . . . . . 10 75 5.3. Benefit from Knowledge . . . . . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 11 80 10. Informative References . . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 The general goals and relevant definitions for autonomic networking 86 are discussed in [I-D.irtf-nmrg-autonomic-network-definitions]. In 87 summary, the fundamental goal of an autonomic network is self- 88 management, including self-configuration, self-optimization, self- 89 healing and self-protection. Whereas interior gateway routing 90 protocols such as OSPF and IS-IS largely exhibit these properties, 91 most other aspects of networking require top-down configuration often 92 involving human administrators and a considerable degree of 93 centralisation. In essence Autonomous Networking is putting all 94 network configuration onto the same footing as routing, limiting 95 manual or database-driven configuration to an essential minimum. It 96 should be noted that this is highly unlikely to eliminate the need 97 for human administrators, because many of their essential tasks will 98 remain. The idea is to eliminate tedious and error-prone tasks, for 99 example manual calculations, cross-checking between two different 100 configuration files, or tedious data entry. Higher level operational 101 tasks, and trouble-shooting, will remain to be done in any case. 103 Note in draft: This is a preliminary version. It certainly lacks 104 information about current status, and it lacks many external 105 references. Especially the final section (Section 5) is very 106 preliminary. Comments and suggestions are very welcome. 108 2. Terminology 110 The terminology defined in 111 [I-D.irtf-nmrg-autonomic-network-definitions] is used in this 112 document. Additional terms include: 114 o Automatic: A process that occurs without human intervention, with 115 step-by-step execution of rules. However it relies on humans 116 defining the sequence of rules, so is not Autonomic in the full 117 sense. For example, a start-up script is automatic but not 118 autonomic. 120 3. Current Status of Autonomic Aspects of IP Networks 122 This section discusses the history and current status of autonomy in 123 various aspects of network configuration, in order to establish a 124 baseline for the gap analysis. In one particular area, routing 125 protocols, autonomic information exchange and decision is a well 126 established mechanism. The question is how to extend autonomy to 127 cover all kinds of network management objectives. 129 3.1. IP Address Management and DNS 131 Originally there was no alternative to completely manual and static 132 management of IP addresses. Once a site had received an IPv4 address 133 assignment (usually a Class C /24 or Class B /16, and rarely a Class 134 A /8) it was a matter of paper-and-pencil design of the subnet plan 135 (if relevant) and the addressing plan itself. Subnet prefixes were 136 manually configured into routers, and /32 addresses were assigned 137 administratively to individual host computers, and configured 138 manually by system administrators. Records were typically kept in a 139 plain text file or a simple spreadsheet. 141 Clearly this method was clumsy and error-prone as soon as a site had 142 more than a few tens of hosts, but it had to be used until DHCP 143 [RFC2131] became a viable solution during the second half of the 144 1990s. DHCP made it possible to avoid manual configuration of 145 individual hosts (except, in many deployments, for a small number of 146 servers configured with static addresses). 148 In terms of management, it is difficult to separate IP address 149 management from DNS management. At roughly the same time as DHCP 150 came into widespread use, it became very laborious to manually 151 maintain DNS source files in step with IP address assignments. 152 Because of reverse DNS lookup, it also became necessary to synthesise 153 DNS names even for hosts that only played the role of clients. 154 Therefore, it became necessary to synchronise DHCP server tables with 155 forward and reverse DNS. For this reason, Internet Protocol address 156 management tools emerged. These are, however, a centralised and far 157 from autonomic type of solution. 159 A related issue is prefix delegation, especially in IPv6 when more 160 than one prefix may be delegated to the same physical subnet. DHCPv6 161 Prefix Delegation [RFC3633] is a useful solution, but how this topic 162 is to be handled in home networks is still an open question. Still 163 further away is automated assignment and delegation of IPv4 subnet 164 prefixes. 166 Another complication is the possibility of Dynamic DNS Update 167 [RFC2136]. With appropriate security, this is an autonomic approach, 168 where no human intervention is required to create the DNS records for 169 a host. Also, there are coexistence issues with a traditional DNS 170 setup. 172 3.2. Routing 174 Since a very early stage, it has been a goal that Internet routing 175 should be self-healing when there is a failure of some kind in the 176 routing system (i.e. a link or a router goes wrong). Also, the 177 problem of finding optimal routes through a network was identified 178 many years ago as a problem in mathematical graph theory, for which 179 well known algorithms were discovered (the Dijkstra and Bellman-Ford 180 algorithms). Thus routing protocols became largely autonomic in the 181 1980s, as soon as the network was big enough for manual configuration 182 of routing tables to become difficult. 184 IGP routers do need some initial configuration data to start up the 185 autonomic routing protocol. Also, BGP-4 routers need static 186 configuration of routing policy data. So far, this policy 187 configuration has not been made autonomic at all. 189 3.3. Configuration of Default Router 191 Originally this was a manual operation. Since the deployment of 192 DHCP, this has been automatic as far as most IPv4 end systems are 193 concerned, but the DHCP server must be appropriately configured. In 194 simple environments such as a home network, the DHCP server resides 195 in the same box as the default router, so this configuration is also 196 automatic. In more complex environments, where an independent DHCP 197 server or a local DHCP relay is used, configuration is more complex 198 and not automatic. 200 In IPv6 networks, the default router is provided by Router 201 Advertisement messages [RFC4861] from the router itself, and all IPv6 202 hosts make use of it. The router may also provide more complex Route 203 Information Options. The process is automatic as far as all IPv6 end 204 systems are concerned, and DHCPv6 is not involved. Howwever there 205 are still open issues when more than one prefix is in use on a subnet 206 and more than one first-hop router may be available as a result. 208 3.4. Hostname Lookup 210 Originally host names were looked up in a static table, often 211 referred to as /etc/hosts from its traditional file path in Unix 212 systems. When the DNS was deployed during the 1980s, all hosts 213 needed DNS resolver code, and needed to be configured with the IP 214 addresses (not the names) of suitable DNS servers. Like the default 215 router, these were originally manually configured. Today, they are 216 provided automatically via DHCP or DHCPv6 [RFC3315]. For IPv6 end 217 systems, there is also a way for them to be provided automatically 218 via a Router Advertisement option. However, the DHCP or DHCPv6 219 server, or the IPv6 router, need to be configured with the 220 appropriate DNS server addresses. 222 3.5. User Authentication and Accounting 224 Originally, user authentication and accounting are mainly based on 225 the physical connectivities. Network operators charged based on the 226 set up of dedicated physical links with users. Autonomic user 227 authentication are introduced by Point-to-Point Protocol [RFC1661], 228 [RFC1994] and RADIUS protocol [RFC2865], [RFC2866] in early 1990s. As 229 long as a user complete online authentication through RADIUS 230 protocol, the accounting for that user starts on AAA server 231 autonomically. This mechanism enables charging business model based 232 on the usage of users, either traffic based or time based. However, 233 the management for user authentication information remains manual by 234 network administrators. 236 3.6. Security 238 Security has many aspects that need configuration and are therefore 239 candidates to become autonomic. On the other hand, it is essential 240 that a network's central policy should be applied strictly for all 241 security configuration. As a result security has largely been based 242 on centrally imposed configurations. 244 Many aspects of security depend on policy, for example firewall 245 policies. Policies are by definition human made and will therefore 246 also persist in an autonomic environment. However, policies are 247 becoming more high-level, abstracting for example addressing, and 248 focusing on the user or application. The methods to manage, 249 distribute and apply policy, and to monitor compliance and violations 250 could be autonomic. 252 Today, many security mechanisms show some autonomic properties. For 253 example user authentication via 802.1x allows automatic mapping of 254 users after authentication into logical contexts (typically VLANs). 255 While today configuration is still very important, the overall 256 mechanism displays signs of self-adaption to changing situations. 258 BGP Flowspec [RFC5575] allows a partially autonomic threat defense 259 mechanism, where threats are identified, the flow information is 260 automatically distributed, and counter-actions can be applied. Today 261 typically a human operator is still in the loop to check correctness, 262 but over time such mechanisms can become more autonomic. 264 Negotiation capabilities, present in many security protocols, also 265 display simple autonomic behaviours. In this case a security policy 266 about algorithm strength can be configured into servers but will 267 propagate automatically to clients. A proposal has been made 268 recently for automatic bootstrapping of trust in a network 269 [I-D.behringer-default-secure]. Solutions for opportunistic 270 encryption have been defined [RFC4322], 271 [I-D.farrelll-mpls-opportunistic-encrypt], but these do not adhere to 272 a central policy. 274 3.7. Miscellaneous 276 There are innumerable other properties of network devices and end 277 systems that today need to be configured either manually or using a 278 management protocol such as SNMP [RFC1157] or NETCONF [RFC6241]. In 279 a truly autonomic network, all of these would need to either have 280 satisfactory default values or be configured automatically. Some 281 examples are parameters for tunnels of various kinds, flows (in an 282 SDN context), quality of service, service function chaining, energy 283 management, system identification, NTP configuration etc. Even one 284 undefined parameter would be sufficient to prevent fully autonomic 285 operation. 287 4. Current Non-Autonomic Behaviors 289 In the current networks, many operations are still heavily depending 290 on human intelligence and decision, or on centralised top-down 291 network management systems. These operations are the targets of 292 Autonomic Network technologies. The ultimate goal of Autonomic 293 Network is to replace tedious human operations by autonomic 294 functions, so that the networks can independently run without having 295 to ask human support for routine details, while it remains possible 296 to restore human intervention when unavoidable. Of course, there 297 would still be the absolute minimum of human input required, 298 particularly during the network establishment stage, and during 299 difficult trouble-shooting. 301 This section analyzes the existing human and central dependencies in 302 the current networks. 304 4.1. Network Establishment 306 Network establishment requires network operators to analyze the 307 requirements of the new network, design a network archetecture and 308 topology, decide device locations and capacities, set up hardware, 309 design network services, choose and enable required protocols, 310 configure each device and each protocol, set up user authentication 311 and accounting policies and databases, design and deploy security 312 mechanisms, etc. 314 Overall, these jobs are quite complex work that cannot become fully 315 autonomic in the forseeable future. However, part of these jobs may 316 be able to become autonomic, such as device and protocol 317 configurations and database population. The initial network 318 management policies/behaviors may also be transplanted from other 319 networks and automatically localized. 321 4.2. Network Maintenance & Management 323 The network maintenance and management are very different for ISP 324 networks and enterprise networks. ISP networks have to change much 325 more frequently than enterprise networks, given the fact that ISP 326 networks have to serve a large number of customers who have very 327 diversified requirements. The current rigid model is that network 328 administrators design a limited number of services for customers to 329 order. New requirements of network services may not be able to be 330 met quickly by human management. Given a real-time request, the 331 response must be autonomic, in order to be flexible and quickly 332 deployed. However, behind the interface, describing abstracted 333 network information and user authorization management may have to 334 depend on human intelligence from network administrators in the 335 forseeable future. User identification integration/consolidation 336 among networks or network services are another challenge for 337 autonomic network access. Currently, the end users have to manually 338 manage their user accounts and authentication information when they 339 switch among networks or network services. 341 Classical network maintenance and management mainly manages the 342 configuration of network devices. Tools have developed to enable 343 remote management and make the management easier. However, the 344 decision of each configuration depends either on human intelligence 345 or rigid templates. This is the source of most network configuration 346 errors. It is also the barrier to increase the utility of network 347 resources because the human management cannot respond quickly enough 348 to network events, such as traffic bursts, etc. For example, 349 currently, a light load is normally assumed in network design because 350 there is no mechanism to properly handle a sudden traffic flood. It 351 is actually normal to avoid network crashes caused by traffic 352 overload by wasting a huge amount of resources. 354 Autonomic decision processes of configuration would enable dynamic 355 management of network resources (by managing resource relevant 356 configuration). Self-adapting network configuration would adjust the 357 network into the best possible situation, which also prevents 358 configuration errors from having lasting impact. 360 4.3. Troubleshooting and Recovery 362 Current networks suffer difficulties in locating the cause of network 363 failures. Although network devices may issue many warnings while 364 running, most of them are not sufficiently precise to be identified 365 as errors. Some of them are early warnings that would not develop 366 into real errors. Others are in effect random noise. During a major 367 failure, many different devices will issue multiple warnings within a 368 short time, causing overload for the NMS and the operators. However, 369 for many scenarios, human experience is still vital to identify real 370 issues and locate them. This situation may be improved by 371 automatically associating warnings from multiple network devices 372 together. Also, introducing automated learning techniques (comparing 373 current warnings with historical relationships between warnings and 374 actual faults) could increase the possibility and success rate of 375 autonomic network diagnoses and troubleshooting. 377 Depending on the network errors, some of them may always require 378 human interventions, particularly for hardware failures. However, 379 autonomic network management behavior may help to reduce the impact 380 of errors, for example by switching traffic flows around. Today this 381 is usually manual (except for classical routing updates). Fixing 382 software failures and configuration errors currently depends on 383 humans, and may even involve rolling back software versions and 384 rebooting hardware. Such problems could be autonomically corrected 385 if there were diagnostics and recovery functions defined in advance 386 for them. This would fulfill the concept of self-healing. 388 Another possible autonomic function is predicting device failures or 389 overloads before they occur. A device could predict its own failure 390 and warn its neighbors; or a device could predict its neighbor's 391 failure. In either case, an autonomic network could respond as if 392 the failure had already occurred by routing round the problem and 393 reporting the failure, with no disturbance to users. The criteria 394 for predicting failure could be temperature, battery status, bit 395 error rates, etc. The criteria for predicting overload could be 396 increasing load factor, latency, jitter, congestion loss, etc. 398 5. Approach toward Autonomy 400 The task of autonomic networking is to build up individual autonomic 401 decision processes that could properly combine to respond to every 402 type of network event. This section (when complete) will outline 403 what needs to be developed. 405 5.1. More Coordination among Devices or Network Partitions 407 Events in networks are normally not independent. They are associated 408 with each other. But most of current response functions are based on 409 independent processes. The network events that may naturally happen 410 distributed should be associated in the autonomic processes. 412 In order to make right or good decisions autonomically, the network 413 devices need to know more information than just reachability 414 (routing) information from the relevant or neighbor devices. There 415 are dependencies between such information and configurations. 416 Currently, most of these configurations currently require manual 417 coordination by network administrators. 419 There are therefore increased requirements for horizontal information 420 exchanging in the networks. Particularly, negotiation among network 421 devices are needed for autonomic decision. 422 [I-D.jiang-config-negotiation-ps] analyzes such requirements. 423 Although there are many existing protocols with negotiation ability, 424 each of them are only serve a specifc and narrow purpose. 425 [I-D.jiang-config-negotiation-protocol] is one of the attempts to 426 create a generic negotiation platform, which would support different 427 negotiation objectives. 429 5.2. Forecasting and Dry Runs 431 In a conventional network, there is no mechanism for trying something 432 out. That means that configuration changes have to be designed in 433 the abstract and their probable effects have to be estimated 434 theoretically. The only alternative to this would be to test them on 435 a complete and realistic network simulator, which is unlikely to be 436 possible for a network of any size. In any case, there is a risk 437 that applying the changes to the running network will cause a failure 438 of some kind. An autonomic network could fill this gap by supporting 439 a "dry run" mode in which a configuration change could be tested out 440 in the control plane without actually affecting the data plane. If 441 the results are satisfactory, the change could be made live; if there 442 is a problem, the change could be rolled back with no effect on 443 users. 445 5.3. Benefit from Knowledge 447 The more knowledge we have, the more intelligent we are. It is the 448 same for networks and network management. It is when one component 449 in the network lacks knowledge that affects what it should do, and 450 another component has that knowledge, that we usually rely on a human 451 operator or a centralised management tool to convey the knowledge. 453 Up to now, most available network knowledge is only the current 454 network status, either inside a device or relevant data from other 455 devices. 457 However, historic knowledge is very helpful to make correct 458 decisions, in particular to reducing network oscillation or to manage 459 network resources over time. Transplantable knowledge from other 460 networks can be helpful to initially set up a new network or new 461 network devices. Knowledge of relationship between network events 462 and network configuration may help network to decide the best 463 parameters according to real performance feedback. 465 6. Security Considerations 467 This document is focussed on what is missing to allow autonomic 468 network configuration, including of course security settings. 469 Therefore, it does not itself create any new security issues. It is 470 worth underlining that autonomic technology must be designed with 471 strong security properties from the start, since a network with 472 vulnerable autonomic functions would be at great risk. 474 7. IANA Considerations 476 This memo includes no request to IANA. 478 8. Acknowledgements 480 The authors would like to acknowledge the valuable comments made by 481 participants in the IRTF Network Management Research Group and 482 others. 484 This document was produced using the xml2rfc tool [RFC2629]. 486 9. Change log [RFC Editor: Please remove] 488 draft-irtf-nmrg-an-gap-analysis-00: RG comments added, 2014-04-02. 490 draft-jiang-nmrg-an-gap-analysis-00: original version, 2014-02-14. 492 10. Informative References 494 [I-D.behringer-default-secure] 495 Behringer, M., Pritikin, M., and S. Bjarnason, "Making The 496 Internet Secure By Default", draft-behringer-default- 497 secure-00 (work in progress), January 2014. 499 [I-D.farrelll-mpls-opportunistic-encrypt] 500 Farrel, A. and S. Farrell, "Opportunistic Encryption in 501 MPLS Networks", draft-farrelll-mpls-opportunistic- 502 encrypt-02 (work in progress), February 2014. 504 [I-D.irtf-nmrg-autonomic-network-definitions] 505 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 506 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 507 Networking - Definitions and Design Goals", draft-irtf- 508 nmrg-autonomic-network-definitions-00 (work in progress), 509 December 2013. 511 [I-D.jiang-config-negotiation-protocol] 512 Jiang, S., Carpenter, B., Liu, B., and Y. Yin, 513 "Configuration Negotiation Protocol for Network Devices", 514 draft-jiang-config-negotiation-protocol-00 (work in 515 progress), October 2013. 517 [I-D.jiang-config-negotiation-ps] 518 Jiang, S., Yin, Y., and B. Carpenter, "Network 519 Configuration Negotiation Problem Statement and 520 Requirements", draft-jiang-config-negotiation-ps-02 (work 521 in progress), January 2014. 523 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 524 "Simple Network Management Protocol (SNMP)", STD 15, RFC 525 1157, May 1990. 527 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 528 RFC 1661, July 1994. 530 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 531 Protocol (CHAP)", RFC 1994, August 1996. 533 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 534 2131, March 1997. 536 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 537 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 538 RFC 2136, April 1997. 540 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 541 June 1999. 543 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 544 "Remote Authentication Dial In User Service (RADIUS)", RFC 545 2865, June 2000. 547 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 549 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 550 and M. Carney, "Dynamic Host Configuration Protocol for 551 IPv6 (DHCPv6)", RFC 3315, July 2003. 553 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 554 Host Configuration Protocol (DHCP) version 6", RFC 3633, 555 December 2003. 557 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 558 Encryption using the Internet Key Exchange (IKE)", RFC 559 4322, December 2005. 561 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 562 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 563 September 2007. 565 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 566 and D. McPherson, "Dissemination of Flow Specification 567 Rules", RFC 5575, August 2009. 569 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 570 Bierman, "Network Configuration Protocol (NETCONF)", RFC 571 6241, June 2011. 573 Authors' Addresses 575 Michael H. Behringer 576 Cisco Systems 578 Email: mbehring@cisco.com 580 Brian Carpenter 581 Department of Computer Science 582 University of Auckland 583 PB 92019 584 Auckland 1142 585 New Zealand 587 Email: brian.e.carpenter@gmail.com 589 Sheng Jiang 590 Huawei Technologies Co., Ltd 591 Q14, Huawei Campus, No.156 Beiqing Road 592 Hai-Dian District, Beijing, 100095 593 P.R. China 595 Email: jiangsheng@huawei.com