RFC 7576
General Gap Analysis for Autonomic Networking
General Gap Analysis for Autonomic Networking 🎀
Okay bestie, this one's an Informational doc from the IRTF (the research side of the Internet standards world) 🦋. It's RFC 7576, published in June 2015, and it's not a Standards Track spec. The authors are S. Jiang (Huawei Technologies Co., Ltd), B. Carpenter (Univ. of Auckland), and M. Behringer (Cisco Systems). The ISSN is 2070-1721, and the title block doesn't list anything it obsoletes or updates. 💅
Abstract ✨
So the abstract is giving problem statement + gap analysis 🧠. It's about an IP-based Autonomic Network that's mainly built on distributed network devices. The doc looks at how autonomic the IP networks we have today already are, and how much current network management still leans on centralization and human admins 👀. Then it lists the general features that are missing from today's networks and that the ideal Autonomic Network concept would need 🔥. This doc is a product of the IRTF's Network Management Research Group, and yes, that group is iconic 👑.
Status of This Memo 📝
Real talk: this is not an Internet Standards Track spec. It's published just for info 🌸. It's an IRTF product, and the IRTF shares results of Internet-related research and development. Those results might not be suitable for deployment, so don't just yolo them into prod 💀. This RFC represents the consensus of the Network Management Research Group of the IRTF. Docs the IRSG approves for publication are not a candidate for any level of Internet Standard. For the full deal, check out Section 2 of RFC 5741 🫶.
Want the current status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc7576 ✨.
Copyright Notice 🌈
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💜. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions 🙈.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Automatic and Autonomic Aspects of Current IP Networks . . . 3
3.1. IP Address Management and DNS . . . . . . . . . . . . . . 3
3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Configuration of Default Router in a Host . . . . . . . . 5
3.4. Hostname Lookup . . . . . . . . . . . . . . . . . . . . . 5
3.5. User Authentication and Accounting . . . . . . . . . . . 6
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7. State Synchronization . . . . . . . . . . . . . . . . . . 7
4. Current Non-autonomic Behaviors . . . . . . . . . . . . . . . 7
4.1. Building a New Network . . . . . . . . . . . . . . . . . 7
4.2. Network Maintenance and Management . . . . . . . . . . . 8
4.3. Security Setup . . . . . . . . . . . . . . . . . . . . . 9
4.4. Troubleshooting and Recovery . . . . . . . . . . . . . . 9
5. Features Needed by Autonomic Networks . . . . . . . . . . . . 10
5.1. More Coordination among Devices or Network Partitions . . 11
5.2. Reusable Common Components . . . . . . . . . . . . . . . 11
5.3. Secure Control Plane . . . . . . . . . . . . . . . . . . 12
5.4. Less Configuration . . . . . . . . . . . . . . . . . . . 12
5.5. Forecasting and Dry Runs . . . . . . . . . . . . . . . . 13
5.6. Benefit from Knowledge . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Informative References . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 171. Introduction 🦋
Okay so the goals and definitions for Autonomic Networking are all in [RFC7575] 📚. The big idea is self-management: self-configuration, self-optimization, self-healing, and self-protection 💖. Interior gateway routing protocols like OSPF and IS-IS already kinda do this, but most other networking stuff still needs top-down config, often with human admins and a lot of centralization 😭. Autonomic Networking basically puts all network config on the same footing as routing, and only keeps manual or database-driven config to an essential minimum ✨.
Now, this is highly unlikely to get rid of human admins, bestie. Plenty of their essential tasks will still be there 🫶. The point is to kill the tedious, error-prone stuff, like manual calculations, cross-checking two config files against each other, or boring data entry 💅. Higher-level ops and complex troubleshooting will still be human work 👑.
This doc represents the consensus of the IRTF's Network Management Research Group (NMRG) 🌸. It starts with background by pointing out examples of partial autonomic behavior already on the Internet and describing the important non-autonomic areas. From those observations, it then describes the missing general mechanisms that would let autonomic behaviors be added across the whole Internet 🌈.
2. Terminology 🧚
Quick one: the terminology from [RFC7575] is used here too, so no new vocab to memorize 💜.
3. Automatic and Autonomic Aspects of Current IP Networks 🔥
This section is all about the history and current status of automatic or autonomic operations in different parts of network config. The goal is a baseline for the gap analysis 👀. Routing protocols are the standout here, since they already have autonomic stuff like information exchange and state synchronization 💖.
3.1. IP Address Management and DNS 🎀
For years, IP addresses and prefixes were managed 100% manually and statically 😭. Once a site got an IPv4 address assignment (usually a Class C /24 or Class B /16, and rarely a Class A /8), it was all paper-and-pencil work: the subnet plan (if relevant) and the addressing plan itself ✏️. Subnet prefixes got typed into routers by hand, and /32 addresses were handed out administratively to individual hosts and configured manually by sysadmins. Records usually lived in a plain text file or a basic spreadsheet 🍓.
Honestly, that was clumsy and error-prone as soon as a site had more than a few tens of hosts, but it's what everyone had to use until DHCP [RFC2131] became a viable option in the second half of the 1990s 🌸. DHCP meant you could skip manually configuring individual hosts (except, in lots of deployments, for a few servers with static addresses) 🙌. Even so, prefixes still had to be manually assigned to subnets and their routers, and DHCP servers had to be set up to match 😩.
IP address management and DNS management are linked, because DNS mappings usually need to stay synced with IP address assignments 🔗. Around the time DHCP got popular, manually keeping DNS source files in step with address assignments became super laborious 💀. Reverse DNS lookup made things worse, since names had to be synthesized even for hosts that were only clients 🙈. So DHCP server tables had to be synchronized with forward and reverse DNS. That's why IP address management tools showed up, as discussed for renumbering in [RFC7010]. But these are centralized solutions that don't have the autonomic properties defined in [RFC7575] 🥲.
Prefix delegation is a related issue, especially in IPv6, where more than one prefix may be delegated to the same physical subnet 🌈. DHCPv6 Prefix Delegation [RFC3633] is a useful solution, but it needs specific configuration, so it can't be considered autonomic ⚠️. How this gets handled in home networks is still being discussed [Pfister] 🏠. Autonomic assignment and delegation of routable IPv4 subnet prefixes is even further away 🌙.
An IPv6 network needs several aspects of host address assignment to be configured. The network might use stateless address autoconfiguration [RFC4862] or DHCPv6 [RFC3315] in stateless or stateful modes, and there are various alternative forms of Interface Identifier [RFC7136] 💜.
Dynamic DNS Update [RFC2136] is another feature. With appropriate security, this is an automatic approach where no human intervention is needed to create DNS records for a host after it gets a new address ✨. Coexistence issues with a traditional DNS setup do exist, though, as described in [RFC7010] 👀.
3.2. Routing 🦋
Since a very early stage, the goal has been for Internet routing to be self-healing when something fails in the routing system, like a link or router going wrong 🔥. Finding optimal routes through a network was also identified years ago as a problem in mathematical graph theory, with well-known algorithms discovered for it (the Dijkstra and Bellman-Ford algorithms) 🧠. So routing protocols became largely autonomic from the start, since manually configuring routing tables for a large network was clearly impractical 🙌.
That said, IGP routers do need some initial configuration data to start the autonomic routing protocol 🛠️. And BGP-4 routers need detailed static configuration of routing policy data 😅.
3.3. Configuration of Default Router in a Host 🌸
Originally, setting the default router in a host was a manual job 🥱. Once DHCP was deployed, this became automatic for most IPv4 hosts, but the DHCP server still has to be configured properly 🔧. In simple setups like a home network, the DHCP server lives in the same box as the default router, so that config is automatic too 🏡. In more complex environments, where an independent DHCP server or a local DHCP relay is used, DHCP config gets more involved and isn't automatic 😤.
In IPv6, the default router comes from Router Advertisement messages [RFC4861] sent by the router itself, and all IPv6 hosts use it 💖. The router can also provide more complex Route Information Options 🌈. This is basically autonomic for all IPv6 hosts, and DHCPv6 isn't involved at all ✨. Still, there are open issues when more than one prefix is in use on a subnet, which can mean more than one first-hop router is available as a result (see, for example, [RFC6418]) 👀.
3.4. Hostname Lookup ✨
Okay so back in the day, hostnames got looked up in one static table, the famous "hosts.txt" file 📄. Then DNS showed up during the 1980s and suddenly every host needed DNS resolver code 💻 and had to be set up with the IP addresses (not the names!) of suitable DNS servers 🧚. Just like the default router, those were manually configured, bestie 🥲. Nowadays they get handed out automatically through DHCP or DHCPv6 [RFC3315] 🎀. IPv6 end systems can also grab them automatically via a Router Advertisement option 🦋. BUT the DHCP or DHCPv6 server, or the IPv6 router, still needs to be configured with the right DNS server addresses, so it's not totally hands-off 💅. Also, some networks run Multicast DNS [RFC6762] locally to add extra automation to the name space 🌈 ngl that's giving very helpful vibes ✨.
3.5. User Authentication and Accounting 💖
Originally, user authentication and accounting was mainly based on physical connectivity and the degree of trust that came with direct connection 🔌. Network operators charged based on how dedicated physical links were set up with users 💸. Automated user authentication showed up in the early 1990s with the Point-to-Point Protocol [RFC1661], [RFC1994] and the RADIUS protocol [RFC2865] [RFC2866] 🔥. As long as a user finishes online authentication through RADIUS, accounting for that user starts automatically on the matching Authentication, Authorization, and Accounting (AAA) server 🙌. This is what makes business models with charging based on traffic amount or time possible 🍓. HOWEVER, user authentication information still gets manually managed by network administrators 😭. It also gets messy for mobile users who roam between operators, since those operators need prior relationships with each other 🙈.
3.6. Security 🔐
Security has lots of aspects that need configuration, so they're candidates to become autonomic 🤖. On the other hand, a network's central policy has to be applied strictly for all security configurations 👑. So security has mostly been based on centrally imposed configurations, periodt 💅.
Many aspects of security depend on policy, like password rules, privacy rules, firewall rulesets, intrusion detection and prevention settings, VPN configurations, and the choice of cryptographic algorithms 🧁. Policies are, by definition, human made, so they'll also stick around in an autonomic environment 🫶. That said, policies are getting more high-level, abstracting addressing for example, and focusing on the user or application 💜. The methods to manage, distribute, apply, and monitor compliance and violations of policy could be autonomic ✨.
Today, many security mechanisms already show some autonomic properties 🦋. For example, user authentication via IEEE 802.1x automatically maps users after authentication into logical contexts (typically VLANs) 🎀. Configuration is still super important, but the overall mechanism shows signs of self-adaption to changing situations 🌸.
BGP Flowspec [RFC5575] allows a partially autonomic threat-defense mechanism, where threats get identified, flow information is automatically distributed, and counter-actions can be applied 🚨. Today a human operator is typically still in the loop to check correctness, but over time these mechanisms can become more autonomic 👀.
Negotiation capabilities, present in many security protocols, also show simple autonomic behaviors 🤝. Here a security policy about algorithm strength can be configured into servers and will propagate automatically to clients 🌟.
3.7. State Synchronization 🔄
Another area where autonomic processes between peers are involved is state synchronization 🫧. Several devices start out with inconsistent state and go through a peer-to-peer procedure, after which their states are consistent 💞. Lots of autonomic or automatic processes include some degree of implicit state synchronization 🌈. Network time synchronization [RFC5905] is a well-established explicit example 🕰️, guaranteeing that a participating node's clock state is synchronized with reliable time servers within a defined margin of error, with no overall point of control for the synchronization process 👑 literally so cool.
- Current Non-autonomic Behaviors 🙅♀️
In current networks, many operations still depend heavily on human intelligence and decision-making, or on centralized top-down network management systems 🧠. These operations are the targets of Autonomic Networking technologies 🎯. The ultimate goal of Autonomic Networking is to replace human and automated operations with autonomic functions, so networks can run independently without depending on a human or Network Management System (NMS) for routine details, while still maintaining central control where required 🌟. Of course, there would still be an absolute minimum of human input required, especially during network building, emergencies, and difficult troubleshooting 🆘.
This section looks at the existing human and central dependencies in typical networks and suggests cases where they could, in principle, be replaced by autonomic behaviors 🔍.
4.1. Building a New Network 🏗️
Building a network requires the operator to analyze the requirements of the new network, design a deployment architecture and topology, decide device locations and capacities, set up hardware, design network services, choose and enable required protocols, configure each device and each protocol, set up central user authentication and accounting policies and databases, design and deploy security mechanisms, etc. 😮💨
Overall, these jobs are seriously complex and can't become fully autonomic in the foreseeable future 🙃. However, some of these jobs may be able to become autonomic, like detailed device and protocol configurations and database population 💻. The initial network management policies and behaviors may also be transplanted from other networks and automatically localized 🦋.
4.2. Network Maintenance and Management 🛠️
Network maintenance and management are very different for ISP networks and enterprise networks 🏢. ISP networks have to change way more frequently than enterprise networks, given that ISP networks serve a huge number of customers with very diversified requirements 📈. The current rigid model is that network administrators design a limited number of services for customers to order 📋. New requirements for network services may not be met quickly by human management 🐢. Given a real-time request, the response must be autonomic, so it stays flexible and can be deployed quickly ⚡. However, behind the interface, describing abstracted network information and managing user authorization may have to depend on human intelligence from network administrators for the foreseeable future 🧑💻. User identification integration and consolidation among networks or network services is another challenge for Autonomic Network access 🔗. Right now, many end users have to manually manage their user accounts and authentication information when they switch among networks or network services 😩.
Classical network maintenance and management mainly handles the configuration of network devices 🔧. Tools have been developed to enable remote management and make it easier 📱. However, the decision about each configuration detail depends on either human intelligence or rigid templates 🤷♀️. Therefore, these are the sources of all network configuration errors -- the human was wrong, the template was wrong, or both were wrong 💀. This is also a barrier to increasing the utility of network resources, because human managers can't respond quickly enough to network events, like traffic bursts, that weren't foreseen in the template 🌊. For example, right now a light load is often assumed in network design, because there's no mechanism to properly handle a sudden traffic flood 🌩️. So it's common to avoid performance collapses caused by traffic overload by configuring idle resources, with an overprovisioning ratio of at least 2 being normal [Xiao02] 🥴.
There are grounds for concern that new, more flexible methods of network configuration, typified by Software-Defined Networking (SDN), will only make the management problem more complex unless the details are managed automatically or autonomically 😬. There's no doubt that SDN creates both the necessity and the opportunity for automation of configuration management, e.g., [Kim13] 🚀. This topic is discussed from a service provider viewpoint in [RFC7149] 📚.
Autonomic decision processes for configuration would enable dynamic management of network resources (by managing resource-relevant configuration) 🌈. Self-adapting network configuration would adjust the network into the best possible situation, and this would prevent configuration errors from having lasting impact 💖.
4.3. Security Setup 🔒
Setting up security for a network generally requires very detailed human intervention, or relies entirely on default configurations that may be too strict or too risky for the particular situation of the network 😵. While some aspects of security are intrinsically top-down in nature (e.g., broadcasting a specific security policy to all hosts), others could be self-managed within the network 🧚♀️.
In an Autonomic Network, where nodes within a domain have a mutually verifiable domain identity, security processes could run entirely automatically 🤩. Nodes could identify each other securely, negotiating required security settings and even shared keys if needed 🔑. The locations of the trust anchors (certificate authority, registration authority), certificate revocation lists, policy server, etc., can be found by service discovery 🔍. Transactions such as a download of a certificate revocation list can be authenticated via a common trust anchor 🛡️. Policy distribution can also be entirely automated and secured via a common trust anchor 📜.
These concepts lead to a network where the intrinsic security is automatic and applied by default, i.e., a "self-protecting" network 💅✨. For further discussion, see [Behringer] 📖.
4.4. Troubleshooting and Recovery ✨
Okay so, networks are SO bad at figuring out what actually went wrong 😭. Devices throw out loads of warnings while they're running, and most of them aren't precise enough to count as errors. Some are early heads-ups that never turn into real problems, and others are basically random noise 🙈. When a big failure hits, a bunch of different devices all start yelling warnings at once, and the NMS and the operators get totally overloaded. It's chaos, bestie.
Humans still have to do a lot of the detective work for many scenarios, because experience matters 💅. This could get better if warnings from multiple devices were automatically linked together. Automated learning could help too: comparing current warnings with past relationships between warnings and real faults could make Autonomic Network diagnoses and troubleshooting more likely to work, and more successful 🧚.
Some errors, especially hardware failures, will always need a human to step in 🛠️. But an Autonomic Network can still lower the impact of errors, for example by moving traffic flows around. Right now that's usually manual (except for the classic routing updates). Fixing software failures and configuration mistakes depends on people right now, and it can even mean rolling back software versions and rebooting hardware 💀. These problems could be fixed autonomically if diagnostics and recovery functions were defined in advance. That would be the whole self-healing vibe 🩹✨.
Another possible autonomic move is predicting device failures or overloads before they happen 🔮. A device could predict its own failure and warn its neighbors, or it could predict a neighbor's failure. Either way, an Autonomic Network could act as if the failure had already happened, routing around the problem and reporting it, with no disruption to users 👑. The signals for predicting failure could be things like temperature, battery status, bit error rates, and so on. The signals for predicting overload could be a rising load factor, latency, jitter, congestion loss, and so on 🌈.
5. Features Needed by Autonomic Networks 🎀
Okay this part is kind of wild. There are SO many properties of network devices and end systems that people have to configure by hand, by scripting, or with a management protocol like the Network Configuration Protocol (NETCONF) [RFC6241] 😩. In an Autonomic Network, all of these would need to either have good default values or get configured automatically. Some examples are parameters for tunnels of various kinds, flows (in an SDN context), quality of service, service function chaining, energy management, system identification, and NTP configuration. And honestly, the list goes on forever 🫠.
The goal of Autonomic Networking is to gradually build individual autonomic processes that can be combined step by step to respond to every type of network event 🦋. Building on the background above, and on the reference model in [RFC7575], this section lays out the gaps and missing features in general terms. In some cases it also mentions general design principles that should apply 🧠.
5.1. More Coordination among Devices or Network Partitions 🍓
Network services depend on a bunch of devices and parameters being in place in a certain order. For example, after a power failure, a coordinated "return to normal" sequence is desirable, like switches and routers first, then DNS servers, and so on 🔌. Right now, the correct order is either known only by a human admin or automated in a central script. In a truly Autonomic Network, elements should understand their dependencies and be able to resolve them locally 💖.
To make right or good decisions autonomically, network devices need to know more than just reachability (routing) information from relevant or neighboring devices. Devices must be able to work out, for themselves, the dependencies between that information and configurations 🧩.
So there's a bigger need for horizontal information exchange across networks. In particular, three types of interaction among peer devices are needed for autonomic decisions: discovery (finding neighbors and peers), synchronization (agreeing on network status), and negotiation (when things need to change) 🤝. That means we need reusable discovery, synchronization, and negotiation mechanisms that can support discovering many different types of device, synchronizing many types of parameter, and negotiating many different types of objective 🔥.
5.2. Reusable Common Components 🧰
Pieces of autonomic functions already exist today, inside lots of different protocols. But every one of those functions has its own discovery, transport, messaging, and security mechanisms, plus non-autonomic management interfaces 😤. Each protocol has its own version of these functions to serve specific, narrow purposes. It's often hard to extend an existing protocol to serve different purposes. So to provide the reusable discovery, synchronization, and negotiation mechanisms mentioned above, it's desirable to build a set of reusable common protocol components for Autonomic Networking. These components should be:
- Able to identify other devices, users, and processes securely.
- Able to automatically secure operations, based on the identity scheme above.
- Able to manage any type of information and information flows.
- Able to discover peer devices and services for various Autonomic Service Agents (or autonomic functions).
- Able to support closed-loop operations when needed, to provide self-managing functions involving more than one device.
- Separable from the specific Autonomic Service Agents (or autonomic functions).
- Reusable by other autonomic functions.
5.3. Secure Control Plane 🔐
The common components will basically act as a control plane for autonomic operations. This control plane might be implemented in-band as functions of the target network, in an overlay network, or even out-of-band in a separate network 🛰️. Autonomic operations will be able to change how the network operates and allocate resources without any human intervention or knowledge, so it is essential that they are secure 🚨. So the control plane must be designed to be secure against forged autonomic operations and man-in-the-middle attacks, and as secure as reasonably possible against denial-of-service attacks. It must still be decided whether the control plane needs to resist unwanted monitoring, meaning whether encryption is required 👀.
5.4. Less Configuration 🌸
Lots of existing protocols were designed to be as flexible as possible. Because of that, they need tons of initial configuration just to start running 😵💫. There are choices and options that don't matter in any particular case, and some of them target weird corner cases. Also, in protocols that have been around for years, some design considerations no longer make sense, since the underlying hardware has evolved in the meantime. To see how big this problem is, consider that more than 160 DHCP options have been defined for IPv4. Even sample router configuration files you can find online contain more than 200 lines of commands 📜. So there's a lot of room to simplify the operational tools used to configure common protocols, even if the underlying protocols themselves can't be simplified.
Here's the deeper point: the real reason humans often have to make decisions is a lack of information. When a device can collect enough information horizontally from other devices, it should be able to decide many parameters by itself, instead of waiting for them to be pushed from the top down 💅.
Top-down management should be reduced in Autonomic Networking. Ideally, the only thing needed from human administrators is the abstract Intent. Neither users nor administrators should have to create and maintain detailed policies and profiles. If those are needed, they should be built autonomically ✨. Local parameters should be decided by the distributed Autonomic Nodes themselves, using historic knowledge, analytics of current conditions, closed logical decision loops, or a mix of all of these 🦋.
5.5. Forecasting and Dry Runs 🔮
In a conventional network, there's no safe way to try something out first. That means configuration changes have to be designed in the abstract, and their likely effects have to be estimated in theory 🫠. In principle, you could test changes on a complete, realistic network simulator. But that's a practical impossibility for a large network that's constantly changing, even if an accurate simulation could be run. So applying changes to a live network always carries a risk that something fails 😬. An autonomic network could fill this gap by supporting a closed-loop "dry run" mode, where each configuration change is tested dynamically in the control plane without actually touching the data plane 🧪. If the results look good, the change can go live on the running network. If there's a consistency problem, like overcommitted resources or an incompatibility with another configuration setting, the change can be rolled back dynamically with no impact on traffic or users 🙌.
5.6. Benefit from Knowledge 🧠
The more knowledge and experience we have, the better decisions we can make. It's the same for networks and network management 💜. When one component lacks knowledge that affects what it should do, and another component has that knowledge, we usually rely on a human operator or a centralized management tool to pass it along 📨.
Up to now, the only network knowledge available is usually the current status inside a given device, or relevant current status from other devices 🙃.
Historic knowledge is very helpful for making correct decisions. In particular, it can reduce network oscillation or help manage network resources over time 📈. Transplantable knowledge from other networks can help set up a new network or new network devices from the start 🌈. Knowing the relationships between network events and network configuration can help a network choose the best parameters based on real performance feedback 🎯.
On top of that historic knowledge, powerful data analytics of current network conditions can also be a valuable source of knowledge that Autonomic Nodes can use directly ⭐.
6. Security Considerations 🔐💀
Okay, this is the serious part, bestie 🫶. This document is focused on what's missing to allow autonomic network configuration, including security settings, obviously. So it does not, by itself, create any new security issues. But it's worth really underlining that autonomic technology must be designed with strong security properties from the very start, because a network with vulnerable autonomic functions would be at great risk 🚨🔥.
7. Informative References 📚
okay bestie, this is the receipts section 🧾 every source the RFC leans on, listed with all the details so nobody can say we made stuff up. The entries are copied exactly as written so the citations stay accurate 💅
[Behringer]
Behringer, M., Pritikin, M., and S. Bjarnason, "Making The
Internet Secure By Default", Work in Progress,
draft-behringer-default-secure-00, January 2014.
[Kim13] Kim, H. and N. Feamster, "Improving Network Management
with Software Defined Networking", IEEE Communications
Magazine, pages 114-119, February 2013.
[Pfister] Pfister, P., Paterson, B., and J. Arkko, "Distributed
Prefix Assignment Algorithm", Work in Progress,
draft-ietf-homenet-prefix-assignment-07, June 2015.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<http://www.rfc-editor.org/info/rfc1661>.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, DOI 10.17487/RFC1994, August
1996, <http://www.rfc-editor.org/info/rfc1994>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000,
<http://www.rfc-editor.org/info/rfc2866>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418,
DOI 10.17487/RFC6418, November 2011,
<http://www.rfc-editor.org/info/rfc6418>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
DOI 10.17487/RFC7010, September 2013,
<http://www.rfc-editor.org/info/rfc7010>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<http://www.rfc-editor.org/info/rfc7149>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015,
<http://www.rfc-editor.org/info/rfc7575>.
[Xiao02] Xiao, X., Telkamp, T., Fineberg, V., Chen, C., and L. Ni,
"A Practical Approach for Providing QoS in the Internet
Backbone", IEEE Communications Magazine, pages 56-62,
December 2002.Acknowledgements 🫶
Huge thank-yous to everyone in the IRTF Network Management Research Group who gave valuable comments 💖 The authors really appreciated that input. Kevin Fall and Rene Struik gave reviews that were especially helpful, and we are so grateful 🌸
Authors' Addresses 💌
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
China
EMail: jiangsheng@huawei.com
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
EMail: brian.e.carpenter@gmail.com
Michael H. Behringer
Cisco Systems
Building D, 45 Allee des Ormes
Mougins 06250
France
EMail: mbehring@cisco.comThat's the whole doc, bestie 🦋✨ the authors are right there if you wanna reach out 💜
📦 where this page comes from
- ietf: rfc7576 2015-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms