Requirements for IPv6 Routers

This memo defines and discusses requirements for devices that perform forwarding for Internet Protocol version 6 (IPv6). This can include (but is not limited to) the devices described below. Devices which are primarily designed to forward traffic between multiple interfaces. These are normally referred to by the Internet community as routers or, in some cases, intermediate systems. Devices which are designed to modify packets rather than "just" forwarding them. These are often referred to by the Internet community as middleboxes. See for a fuller definition of middleboxes. Readers should recognize that while this memo applies to IPv6, routers and middleboxes IPv6 packets will often also process IPv4 packets, forward based on MPLS labels, and potentially process many other protocols. This memo will only discuss IPv4, MPLS, and other protocols as they impact the behavior of an IPv6 forwarding device; no attempt is made to specify requirements for protocols other than IPv6. The reader should, therefore, not count on this document as a "sole source of truth," but rather use this document as a guide. For IPv4 router requirements, readers are referred to . For simplicity, the term "devices" is used interchangeably with the phrase "routers and middleboxes" and the term "routers" throughout this document. These three terms represent stylistic differences, rather than substantive differences. This document is broken into the following sections: a review of Internet architecture and principles, requirements relating to device management, requirements related to telemetry, requirements related to IPv6 forwarding and addressing, and future considerations. Following these sections, a short conclusion is provided for review.

Shawn Zandi, Pete Lumbis, Fred Baker, and Lee Howard contributed significant text and ideas to this draft.

The editors and contributors would like to thank....

The Internet relies on a number of basic concepts and considerations. These concepts are not explicitly called out in any specification, nor do they necessarily impact protocol design or packet forwarding directly. This section provides an overview of these concepts and considerations to help the reader understand the larger context of this document.

Every point where multiple protocols interact, is an interaction surface that can threaten the robustness of the overall system. While it may seem the global Internet has achieved a level of stability that makes it immune to such considerations, the reality is every network is a complex system, and is therefore subject to massive non repeatable unanticipated failures. Postel's Robustness Principle countered this problem with a simple statement, explicated in : "Be conservative in what you do, and liberal in what you accept from others." However, since this time, it has been noted that following this law allows errors in protocols to accumulate over time, with overall negative effects on the system as a whole. describes several points in conjunction with this principle that bear updating based on further experience with large scale protocol and network deployments within the Internet community, including: Applications should deal with error states gracefully; an application should not degrade in a way that will cause the failure of adjacent systems when possible. For instance, when a routing protocol implementation fails, it should not do so in a way that will cause the spreading of or continued existence of false reachability information, nor should it fail in a way that overloads adjacent routers or interacting protocols and causing a cascading failure. It is best to assume the network is filled with poor implementations and malevolent actors, both of which will find every possible failure mode over time. It is best to assume every technology will be used to the limits of its technical capabilities, rather than assuming a particular protocol's scope of use will align (in any way) with the intent of the original designer(s). defines a wildly sucessful protocol as one that "far exceeds its original goals, in terms of purpose (being used in scenarios far beyond the initial design), in terms of scale (being deployed on a scale much greater than originally envisaged), or both." Successful implementations attract more functionality, much like a few nodes in a scale free graph eventually become connectivity hubs. Protocols and implementations change over time. A corollary of the assumption that protocols will be used until they reach their technical limits is that protocols will change over time as they gain new functionality. points out several problems with "wild success" in a protocol: undesirable side effects, performance problems, and becoming a high value attack target. Protocol and implementation design should take into account use cases that have not yet been thought of by building flexibility into protocols. Protocols should also remained focused on a narrow range of use cases; it is often wise to invent a new protocol than to extend a single protocol into a broad set of use cases. Protocols are sometimes replaced or updated to new versions in order to add new capabilities or features. Updating a protocol requires great care in providing for a transition mechanism between older and newer versions. draft-iab-protocol-transitions provides sound advice on protocol transition planning and mehanisms. Obscure, but legal, protocol features are often ignored or left unimplemented. Protocols must handle receiving unexpected information gracefully so they do not fail because of incomplete or partial implementations. Protocols should avoid specifying contradictory states, or features that will cause interoperability issues if multiple implementations choose to implement different feature sets. Monocultures are almost always bad. While multiple implementations can represent an interaction surface which increases complexity, particularly if a brad set of protocol capabilities and/or implementation features are used, using the same implementation at every point in a deployment results in a monoculture. In a monoculture, a single event can trigger a defect in every router, causing a network failure. Monocultures must be carefully balanced against interaction surfaces; often this is best accomplished by using multiple implementations and minimal, widely implemented, and well understood protocol features. A summary of the points above might be this: It is important to work within the bounds of what is actually implemented in any given protocol, and to leave corner cases for another day. It is often easy to assume "virtual oceans" are easier to boil than physical ones, or for an ocean to appear much smaller because it is being implemented in software. This is often deceptive. It is never helpful to boil the ocean whether in a design, an implementation, or a protocol.

Complexity, as articulated by Mike O'Dell (see ), is "the primary mechanism which impede efficient scaling, and as a result is the primary driver of increases in both capital expenditures (CAPEX) and operational expenditures (OPEX)." At the same time, complexity cannot be "solved," but rather must be "managed." The simplest and most obvious solution to any problem is often easy to design, deploy, and manage. It's also often wrong and/or broken. As much as developers, designers, and operators might like to make things as simple as possible, hard problems require complex solutions. See Alderson and Doyle for a discussion of the relationship between hard problems and complex solutions. The following sections contain observations which apply to the management of complexity in both protocol and network design.

Elegance should be the goal of protocol and network design. Rather than seeking out simple solutions because they are simple, seek out solutions that will solve the problem in the simplest way possible (and no simpler). Often this will require: Ensuring the goal is actually the goal. Many times the goal is taken from the operational realm into the protocol design realm before enough thought has been applied to ensure the correct problem is being addressed. Seeing the problem from different angles, trying to break the problem up in multiple ways; and trying, abandoning, and rebuilding ideas and implementations until a better way is found. Sometimes the complexity of the solution will overwhelm the use case; sometimes it is better to leave the apparent problem unsolved, or allow the community time and space to find a simpler solution.

There are always tradeoffs. For any protocol, network, or operational design decision, there will always be a tradeoff between at least two competing goals. If some problem appears to have a single solution without tradeoffs, this doesn't mean the tradeoffs don't exist. Rather, it means the tradeoffs haven't been discovered yet. In the area of protocol and network design, these tradeoffs often take the form of common "choose two or three" situations, such as "quick, cheap, high quality." In network and protocol design, the tradeoffs are often: The amount of state carried in the system and the speed at which it changes, or simply the state. The amount of state required to operate a system as it scales tends to be nonlinear. Some instances of this are described in section 2.2.1, the Amplification Principle. The number of interaction surfaces between the components that make up the complete system, and the depth of those interaction surfaces. Some examples of surfaces are described in section 2.2.2, the Coupling Principle. Layering is essentially a form of abstraction; all abstractions are subject to the law of leaky abstractions, which states: "all nontrivial absractions leak." The desired optimization, including efficient use of network resources, optimal support for business objectives, and optimal support for a specific set of applications. These three make up a "triangle problem." For instance, to increase the optimization of traffic flow through a network generally requires adding more state to the control plane, leading to problems in complexity due to amplification. To reduce amplification, the control plane (or perhaps the various functions the control plane serves) can be broken up into subsystems, or modules. Breaking the control plane up into subsystems, however, introduces interaction surfaces between the components, which is another form of complexity. provides a good overview of network complexity; in particular, section 3 of that document provides some examples of complexity tradeoffs.

The Internet data plane is organized around broad top and bottom layers, and much thinner middle layer. This is illustrated in the figure below.

This layering emulates or mirrors many naturally occurring systems; it is a common strategy for managing complexity (see Meyer's presentation on complexity). The single protocol in the center, IPv6, serves to separate the complexity of the lower layers from the complexity of the upper layers. This center layer of the Internet ecosystem has traditionally been called the Network Layer, in reference to the Department of Defense (DoD) and OSI models. The Internet ecosystem includes two different protocols in this central location. IPv4, an older network protocol that, it is anticipated, will be replaced over time as the Internet ecosystem standardizes on IPv6 IPv6, a newer network protocol that is being adopted MPLS is often used as a "middle" subtransport layer, and at other times as "middle" sub data link layer; hence MPLS is difficult to classify within the strictly hierarchical model depicted here. These protocols are often treated as if they exist in strict hierarchical layers with a well defined and followed Application Programming Interface (API), data models, Remote Procedure Calls (RPCs), sockets, etc. The reality, however, is there are often solid reasons for violating these layers, creating interaction surfaces that are often deeper than intended or understood without some experience. Beyond this, such layering mechanisms act as information abstractions. It is well known that all such abstractions leak (see above on the law of leaky abstractions). Because of these intentional and unintentional leakages of information, the interactions between protocols is often subtle.

A router connects to two or more logical interfaces and at least one physical interface. A router processes packets by: Receiving a packet through an interface Stripping the data link, physical header, or tunnel encapsulation off the packet Examining the packet for errors, and determining if this packet needs to be punted to another process on the router Looking up the destination in a local forwarding table Rewriting the data link and/or physical layer header Transmitting the packet out an interface When consulting the forwarding table, the router searches for a match based on: The longest prefix containing the destination address (this is the most common matching element) A label, such as a flow label or MPLS label The source address or other header fields (not common) The router then examines the information in the matching entry to determine the next hop, or rather the next logically connected device to forward the packet to. The next hop will either be another router, which will presumably carry the packet closer to the final destination, or it will be the destination host itself. The following figure provides a conceptual model of a router; not all routers actually have this set of tables and interactions, and some have many more moving parts. This model is simply used as a common reference to promote understanding.

| Config | +--+----------+ | | +-------+-----+ | | | | v | | v +-----------------+----+-----------------+ | Running Configuration +------>----------+ +---+----------+----------+----------+---+ | | | | | | v | | | | +-------+ | | | | | IS-IS |<-----------------------------------> Adjacent | +---+---+ v | | Routers | | +-------+ | | | | | BGP |<------------------------> Peers | | +---+---+ v | | | | +-------+ | | | | | OSPF |<-------------> Adjacent | | | +---+---+ v Routers | | | | +-------+ | | | | | Other | | | | | +---+---+ | | | | | | +---+----------+----------+----------+---+ | | RIB Manager | | +---+------------------------------------+ | | | +---+------------------------------------+ | | Routing Information Base (RIB) | | +---+------------------------------------+ | | | +---+------------------------------------+ | | Forwarding Information Base (FIB) | | +---+----------+---------------------+---+ | | | | | +---+---+ +---+---+ +---+---+ | | Int 1 | | Int 2 | ... | Int X | <---------------+ +-------+ +-------+ +-------+ ^ | | v Packets In Packets Out ]]>

Network engineering began in the era of Command Line Interfaces (CLIs), and has generally stayed with these CLIs even as the Graphical User Interface (GUI) has become the standard way of interacting with almost every other computing device. Direct human interaction with routers and middleboxes in large scale and complex environments, however, tends to result in an unacceptably low Mean Time Between Mistakes (MTBM), directly impacting the overall availability of the network. In reaction to this, operators have increased their reliance on automation, specifically targetting machine to machine intefaces, such as Remote Procesdure Calls (RPCs) and Application Programming Interface (API) solutions, to manage and configure routers and middleboxes. This section considers the various components of device management.

Configuration primarily relates to the startup, candidate, and running configurations in the router model shown above. In order to deploy networks at scale, operators rely on automated management of router configuration. This effort has traditionally focused on Simple Network Management Protocol (SNMP) Management Information Base (MIBs). In the future, operators expect to move towards open source/open standards YANG models. Vendors and implementors should implement machine readable interfaces with overlays to support human interaction, rather than human readable interfaces with overlays to support machine to machine interaction. Emphasis should be placed on machine to machine interaction for day to day operations, rather than on human readable interfaces, which are largely used in the process of troubleshooting. Within the realm of machine to machine interfaces, emphasis should be placed on marshaling information in YANG models. To support automated router configuration, IPv6 routers and routers SHOULD support YANG and SNMP configuration, including (but not limited to): Openconfig models related to the protocols configured on the device, interface state, and device state : A YANG Data Model for Interface Management : IANA Interface Type YANG Module : A YANG Data Model for IP Management : A YANG Data Model for System Management Simple Network Management Protocol (SNMP) MIBs as appropriate

To operate a network at scale, operators rely on the ability to access routers and middleboxes to troubleshoot and gather state manually through a number of different interfaces. These interfaces should provide current device configuration, current device state (such as interface state, packets drops, etc.), and current control plane contents (such as the RIB in the figure above). In other words, manual interfaces should provide information about the router (the whole device stack). To support manual state gathering and troubleshooting, IPv6 routers and middleboxes SHOULD support: TELNET (): TELNET SHOULD be disabled by default, but should be available for operational purposes as required or as configured by the operator SSH (): SSH SHOULD be the default access for IPv6 capable routers

To operate a network at scale, operators rely on protocols and mechanisms that reduce provisioning time to a minimum. The preferred state is zero touch provisioning; plug a new router in and it just works without any manual configuration. The closer an operator can come to this ideal, the more MTBM and Operational Expenses (OPEX) can be reduced -- an important goals in the real world. IPv6 routers should support several standards, including, but not limited to: : Dynamic Configuration Protocol for IPv6 SLAAC ( and ): SLAAC SHOULD be enabled by default on all router interfaces SLAAC SHOULD be able to be disabled by operators who prefer to use some other mechanism for address management and assignment.

(Need some text here)

Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks are unfortunately common in the Internet globally; these types of attacks cost network operators a great deal in opportunity and operational costs in prevention and responses. To provide for effective counters to DoS and DDoS attacks directly on routers: Manufacturers and system integrators should test and clearly report the packet/traffic load handling capabilities of devices with and without various encryption methods enabled Routers should be able to police traffic destined to the control plane based on the rate of traffic received, including the ability ot police individual flows, targeted services, etc., at individual rates as described in Ideally, devices should be able to statefully filter traffic destined to the control plane There are other useful techniques for dealing with DDoS attacks at the network level, including: transferring sessions to a new address and abandoning the address under attack, using BGP communities to spread the attack over multiple ingress ports and "consume" it, and requiring mutual authentication before allocating larger resource pools to a connection. These techniques are not "device level," and hence are not considered further here.

Telemetry relates to information devices push to systems used to monitor and track the state of the network. This applies to individual devices as well as the network as a system. Two major challenges face operators in the area of telemetry: Information that is laid out primarily for human, rather than machine, consumption. While human consumption of telemetry is important in some situations, this information should be supplied in a form that focuses on machine readability with an overlay or interpretor that allows human consumption. Software systems that require information to be queried (or polled or even pushed) on a per-item basis. This form of organization can produce a lot of information, and a lot of individual packets, very quickly, overwhelming monitoring systems and consuming a large amount of available network resources. Instead, telemetry should be focused on bulk collection. There are three broad categories of telemetry: device state and traceability, topology state and traceability, and flow traceability. These three roughly correspond to the management plane, the control plane, and the forwarding plane of the network. Each of the sections below considers one of these three telemetry types.

Ideally, the entire network could be monitored using a single modeling language to ease implementation of telemetry systems and increase the pace at which new software can be deployed in production environments. In real deployments, it is often impossible to reach this ideal; however, reducing the languages and methods used, while focusing on machine readibility, can greatly ease the deployment and management of a large scale network. Specifically, IPv6 routers SHOULD support: : NETCONF/RESTCONF transporting telemetry formatted according to YANG (see above) : Syslog gRPC based telemetry interfaces SNMP as appropriate Syslog and SNMP access for telemetry should be considered "legacy," and should not be the focus of new telemetry access development efforts.

IPv6 routers are part of a system of devices that, combined, make up the entire network. Viewing the network as a system is often crucial for operational purposes. For instance, being able to understand changes in the topology and utlization of a network can lead to insights about traffic flow and network growth that lead to a greater understanding of how the network is operating, where problems are developing, and how to improve the network's performance. To support systemic monitoring of the network topology, IPv6 devices SHOULD support at least: : North-Bound Distribution of Link-State and Traffic Engineering (TE) Information using BGP : An I2RS model for layer 2 topologies : An I2RS model for layer 3 topologies : A Data Model for Network Topologies

(To be added)

There are a number of capabilities that a device SHOULD have to be deployed into an IPv6 network, and several forwarding plane considerations operators and vendors need to bear in mind. The sections below explain these considerations.

The IPv6 address is commonly treated as a host identifier; it is not. Rather, it is an interface identifier that describes the topological point where a particular host connects to the Internet. Specifically: The IPv6 address will change when a device changes where it connects to the network. A single host can have multiple addresses. For instance, a host may have one address per interface, or multiple addresses assigned through different mechanisms, or through multiple connection points. A single IPv6 address may represent many hosts, as in the case of a group of hosts reachable through multicast address, or a set of services reachable through an anycast address. Because the host address may change at any time, it is generally harmful to embed IPv6 addresses inside upper layer headers to identify a particular host.

Internet Routing Registries may allocate a network operator a wide range of prefix lengths (see for further information). Within this allocation, network operators will often suballocate address space along nibble boundaries (/48, /52, /56, /60, and /64) for ease of configuration and management. Several common practices are: Each multiaccess interface is allocated a /64 Point-to-point links are allocated a /64, but SHOULD be addressed with a longer prefix length to prevent certain kinds of denial of service attacks ( originally mandated 64 bit prefix lengths on point-to-point links; explains possible security issues with assigning a 64 bit prefix length to a point-to-point, and recommends a /127 instead) Although aggregation may only performed to the nibble boundaries noted above, variances are possible Loopback addresses are assigned a /128 Given these common practices, routers designed to run IPv6 SHOULD support the following addressing conventions: The default prefix length on any interface other than a loopback SHOULD be a /64 Configuring a prefix length longer than a /64 on any multi-access interface should require additional configuration steps to prevent manual configuration errors Routers SHOULD NOT assume IPv6 prefix lengths only on nibble boundaries Routers SHOULD support any prefix length shorter or greater than /64 Loopback interfaces SHOULD default to a /128 prefix length unless some additional configuration is undertaken to override this default setting

The long history of the Maximum Transmission Unit (MTU) in networks is not a happy one. Specific problems with MTU sizing include: Many different default sizes on different media types, from very small (576 bytes on X.25) to very large (17914 bytes on 16Mbps Token Ring) Many different ways to calcualte the MTU on any given link; for instance a 9000 byte MTU can be calculated as 8184 bytes on one operating system, 8972 on another, and 9000 on a third The increasing use of tunnel encapsulations in the network; for instance MPLS over GRE over IP over... The wide variety of default MTUs across many different end hosts and operating systems The general ineffectiveness of path MTU discovery to operate correctly in the face of packet filters and rate limiters (see the section on ICMP filtering below) Lower speed links at the network edge which require a lot of time to serialize a packet with a large MTU Increased jitter caused by the disparity between large and small packet size across a lower bandwidth links The final point requires some further elucidation. The time required to serialize various packets at various speeds are: 64 byte packet onto a 10Mb/s link: .5ms 1500 byte packet onto a 10Mb/s link: 1.2ms 9000 byte packet onto a 10Mb/s link: 7.2ms 64 byte packet onto a 100Mb/s link: .05ms 1500 byte packet onto a 100Mb/s link: .12ms 9000 byte packet onto a 100Mb/s link: .72ms A 64 byte packet trapped behind a single 1500 byte packet on a 10Mb/s link suffers 1.2ms of serialization delay. Each additional 1500 byte packet added to the queue in front of the 64 byte packet adds and addtional 1.2ms of delay. In contrast, a 64 byte packet trapped behind a single 9000 byte packet on a 10Mb/s link suffers 7.7ms of serialization delay. Each additional 9000 byte packet added to the queue adds an additional 7.2ms of serialization delay. The practical result is that larger MTU sizes on lower speed links can add a significant amount of delay and jitter into a flow. On the other hand, increasing the MTU on higher speed links appears to add megligable additional delay and jitter. The result is that it costs less in terms of overall systemic performance to use higher MTUs on higher speed links than on lower speed links. Based on this, increasing the MTU across any particular link may not increase overall end-to-end performance, but can greatly enhance the performance of local applications (such as a local BGP peering session, or a large/long standing elephant flow used to transfer data across a local fabric), while also providing room for tunnel encapsulations to be added with less impact on lower MTU end systems. The general rule of thumb is to assume the largest size MTU should be used on higher speed transit only links in order to support a wide array of available link sizes, default MTUs, and tunnel encapsulations. Routers designed for a network or data center core SHOULD support at least 9000 byte MTUs on all interfaces. MTU detection mechanisms, such as IS-IS hello padding, described in , SHOULD be enabled to ensure correct point-to-point MTU configuration. Devices SHOULD also support: : Path MTU Discovery : Path MTU Discovery for IP version 6 : Packetization Layer Path MTU Discovery

Internet Control Message Protocool (ICMP) is described in and . ICMP is often used to perform a traceroute through a network (normally by using a TTL expired ICMP message), for Path MTU discovery, and, in IPv6, for autoconfiguration and neighbor discovery. ICMP is often blocked by middleboxes of various kinds and/or ICMP filters configured on the ingress edge of a provider network, most often to prevent the discovery of reachable hosts and network topology. Routers implementing IPv6: SHOULD NOT filter ICMP unreachables by default, as this has negative impacts on many aspects of IPv6 operation, particularly path MTU SHOULD filter ICMP echo and echo response by default, to prevent the discovery of reachable hosts and topology. SHOULD rate limit the generation of ICMP messages relative to the ability of the device to generate packets and to block the use of ICMP packets being used as part of a distributed denial of service attack SHOULD implement the filtering suggestions in There are implications for path MTU discovery and other useful mechanisms in filtering and rate limiting ICMP. The tradeoff here is between allowing unlimited ICMP, which would allow path MTU detection to work, or limiting ICMP in a way that prevents negative side effects for individual devices, and hence the operational capabilities of the network as a whole. Operators rightly limit ICMP to reduce the attack surface against their network, as well as the opportinity for "perfect storm" events that inadvertently reduce the capability of routers and middleboxes. Hence ICMP can be treated as "quasi-reliable" in many situations; existence of an ICMP message can prove, for instance, that a particular host is unreachable. The non-existence of an ICMP message, however, does not prove a particular host exists or does not.

In order to support treating the "network as a whole" as a single programmable system, it is important for each router have the ability to directly program forwarding information. This programmatic interface allows controllers, which are programmed to support specific business logic and applications, to modify and filter traffic flows without interfering with the distributed control plane. While there are several programmatic interfaces available, this document suggests that the I2RS interface to the RIB be supported in all IPv6 routers. Specifically, these drafts should be supported to enable network programmability: : Filter-Based RIB Data Model : Filter-Based RIB Information Model : A YANG Data Model for Routing Information Base (RIB) : I2RS Traceability

(To be added)

While the transition to IPv6 only networks may take years (or perhaps decades), a number of operators are moving to deploy IPv6 on internal networks supporting transport and data center fabric applications more quickly. Routers and middleboxes that support IPv6 SHOULD support IPv6 only operation, including: Link Local addressing SHOULD be configurable and useable as the primary address on all interfaces on a device. IPv4 and/or MPLS SHOULD NOT be required for proper device operation. For instance, an IPv4 address should not be required to determine the router ID for any protocol. See section 2. Any control plane protocol implementations SHOULD support the recommendations in for operation using link local addresses only.

(To be added)

This document addresses several ways in which devices designed to support IPv6 forwarding. Some of the recommendations here are designed to increase device security; for instance, see the section on device access. Others may intersect with security, but are not specifically targeted at security, such as running IPv6 link local only on links. These are not discussed further here, as they improve the security stance of the network. Other areas discussed in this draft are more nuanced. This section gathers the intersection between operational concerns and security concerns into one place. ICMP security is already considered in the section on ICMP; it will not be considered further here. Link local only addressing wil increase security by removing transit only links within the network as a reachable destination.

Robustness, particularly in the area of error handling, largely improves security if designed and implemented correctly. Many attacks take advantage of mistakes in implementations and variations in protocols. In particular, any feature that is unevenly implemented among a number of implementations often offers an attack surface. Hence, reducing protocol complexity helps reduce the breadth of attack surfaces. Another point to consider at the intersection of robustness and security is the issue of monocultures. Monocultures are in and of themselves a potential attack surface, in that finding a single failure mode can be exploited to take an entire network (or operator) down. On the other hand, reducing the number of implementations for any particular protocol will decrease the set of "random" features deployed in the network. These two goals will often be opposed to one another. Network designers and operators need to consider these two sides of this tradeoff, and make an intelligent decision about how much diversity to implement versus how to control the attack surface represented by deploying a wide array of implementations.

Programmable interfaces, including programmable configuration, telemetry, and machine interface to the routing table, introduce a large attack surface; operators should be careful to ensure this attack surface is properly secured. Specifically: Prevent external access to any administrative access points used for device programmability Use AAA systems to ensure only valid devices and/or users access devices Rate limit the change rate and protect management interfaces from DoS and DDoS attacks Such interfaces should be treated no differently than SSH, SFTP, and other interfaces available to manage routers and middleboxes.

Zero touch provisioning opens a new attack surface; insider attackers can simply install a new device, and assume it will be autoconfigured into the network. A "simple" solution would be to install door locks, but this will likely not be enough; defenses need to be layered to be effective. It is recommended that devices installed in the network need to contain a hardware or software identification system that allows the operator to identify devices that are installed in the network.

The deployment of IPv6 throughout the Internet marks a point in time where it is good to review the overall Internet architecture, and assess the impact on operations of these changes. This document provides an overview of a lot of these changes and lessons learned, as well as providing pointers to many of the relevant documents to understand each topic more deeply.