idnits 2.17.1 draft-ali-ipv6rtr-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1247 has weird spacing: '...xx, xxx xxx...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 18, 2017) is 2623 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1001, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-restconf' is defined on line 1080, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1123, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1132, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-gont-opsec-icmp-ingress-filtering-02 == Outdated reference: A later version (-08) exists of draft-iab-protocol-transitions-05 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-rfc3315bis-06 == Outdated reference: A later version (-01) exists of draft-ietf-i2rs-fb-rib-data-model-00 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-rib-data-model-07 == Outdated reference: A later version (-18) exists of draft-ietf-i2rs-yang-l2-network-topology-03 == Outdated reference: A later version (-16) exists of draft-ietf-i2rs-yang-l3-topology-08 == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-11 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3627 (Obsoleted by RFC 6547) -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 7277 (Obsoleted by RFC 8344) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Kahn 3 Internet-Draft LinkedIn 4 Intended status: Informational J. Brzozowski 5 Expires: August 22, 2017 Comcast 6 R. White 7 LinkedIn 8 February 18, 2017 10 Requirements for IPv6 Routers 11 draft-ali-ipv6rtr-reqs-02 13 Abstract 15 The Internet is not one network, but rather a collection of networks. 16 The interconnected nature of these networks, and the nature of the 17 interconneted systems that make up these networks, is often more 18 fragile than it appears. Perhaps "robust but fragile" is an 19 overstatement, but the actions of each vendor, implementor, and 20 operator in such an interconneted environment can have a major impact 21 on the stability of the overall Internet (as a system). The 22 widespread adoption of IPv6 could, particularly, disrupt network 23 operations, in a way that impacts the entire system. 25 This time of transition is an opportune time to take stock of lessons 26 learned through the operation of large scale networks on IPv4, and 27 consider how to apply these lessons to IPv6. This document provides 28 an overview of the design and architectural decisions that attend 29 IPv6 deployment, and a set of IPv6 requirements for routers, 30 switches, and middleboxes deployed in IPv6 networks. The hope of the 31 editors and contributors is to provide the neccessary background to 32 guide equipment manufacturers, protocol implemenetors, and network 33 operators in effective IPv6 deployment. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 22, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 4 70 1.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 4 71 2. Review of the Internet Architecture . . . . . . . . . . . . . 4 72 2.1. Robustness Principle . . . . . . . . . . . . . . . . . . 4 73 2.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.2.1. Elegance . . . . . . . . . . . . . . . . . . . . . . 6 75 2.2.2. Tradeoffs . . . . . . . . . . . . . . . . . . . . . . 7 76 2.3. Layered Structure . . . . . . . . . . . . . . . . . . . . 8 77 2.4. Routers . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 3. Requirements Related to Device Management and Security . . . 11 79 3.1. Programmable Device Access . . . . . . . . . . . . . . . 11 80 3.2. Human Readable Device Access . . . . . . . . . . . . . . 12 81 3.3. Zero Touch Provisioning . . . . . . . . . . . . . . . . . 12 82 3.4. Authentication, Authorization, and Accounting . . . . . . 12 83 3.5. Device Protection against Denial of Service Attacks . . . 13 84 4. Requirements Related to Telemetry . . . . . . . . . . . . . . 13 85 4.1. Device State and Traceablity . . . . . . . . . . . . . . 14 86 4.2. Topology State and Traceability . . . . . . . . . . . . . 14 87 4.3. Flow Traceability . . . . . . . . . . . . . . . . . . . . 15 88 5. Requirements Related to IPv6 Forwarding and Addressing . . . 15 89 5.1. The IPv6 Address is not a Host Identifier . . . . . . . . 15 90 5.2. Router Handling of IPv6 Addresses . . . . . . . . . . . . 15 91 5.3. Maximum Transmission Unit and Jumbo Frames . . . . . . . 16 92 5.4. ICMP Considerations . . . . . . . . . . . . . . . . . . . 18 93 5.5. Machine Access to the Forwarding Table . . . . . . . . . 19 94 5.6. Processing IPv6 Extension Headers . . . . . . . . . . . . 19 95 5.7. IPv6 Only Operation . . . . . . . . . . . . . . . . . . . 19 96 6. Future Considerations . . . . . . . . . . . . . . . . . . . . 20 97 6.1. Segment Routing . . . . . . . . . . . . . . . . . . . . . 20 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 99 7.1. Robustness and Security . . . . . . . . . . . . . . . . . 20 100 7.2. Programmable Device Access and Security . . . . . . . . . 21 101 7.3. Zero Touch Provisioning and Security . . . . . . . . . . 21 102 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 105 9.2. Informative References . . . . . . . . . . . . . . . . . 22 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 108 1. Introduction 110 This memo defines and discusses requirements for devices that perform 111 forwarding for Internet Protocol version 6 (IPv6). This can include 112 (but is not limited to) the devices described below. 114 o Devices which are primarily designed to forward traffic between 115 multiple interfaces. These are normally referred to by the 116 Internet community as routers or, in some cases, intermediate 117 systems. 119 o Devices which are designed to modify packets rather than "just" 120 forwarding them. These are often referred to by the Internet 121 community as middleboxes. See [RFC7663] for a fuller definition 122 of middleboxes. 124 Readers should recognize that while this memo applies to IPv6, 125 routers and middleboxes IPv6 packets will often also process IPv4 126 packets, forward based on MPLS labels, and potentially process many 127 other protocols. This memo will only discuss IPv4, MPLS, and other 128 protocols as they impact the behavior of an IPv6 forwarding device; 129 no attempt is made to specify requirements for protocols other than 130 IPv6. The reader should, therefore, not count on this document as a 131 "sole source of truth," but rather use this document as a guide. 133 For IPv4 router requirements, readers are referred to [RFC1812]. For 134 simplicity, the term "devices" is used interchangeably with the 135 phrase "routers and middleboxes" and the term "routers" throughout 136 this document. These three terms represent stylistic differences, 137 rather than substantive differences. 139 This document is broken into the following sections: a review of 140 Internet architecture and principles, requirements relating to device 141 management, requirements related to telemetry, requirements related 142 to IPv6 forwarding and addressing, and future considerations. 143 Following these sections, a short conclusion is provided for review. 145 1.1. Contributors 147 Shawn Zandi, Pete Lumbis, Fred Baker, and Lee Howard contributed 148 significant text and ideas to this draft. 150 1.2. Acknowledgements 152 The editors and contributors would like to thank.... 154 2. Review of the Internet Architecture 156 The Internet relies on a number of basic concepts and considerations. 157 These concepts are not explicitly called out in any specification, 158 nor do they necessarily impact protocol design or packet forwarding 159 directly. This section provides an overview of these concepts and 160 considerations to help the reader understand the larger context of 161 this document. 163 2.1. Robustness Principle 165 Every point where multiple protocols interact, is an interaction 166 surface that can threaten the robustness of the overall system. 167 While it may seem the global Internet has achieved a level of 168 stability that makes it immune to such considerations, the reality is 169 every network is a complex system, and is therefore subject to 170 massive non repeatable unanticipated failures. Postel's Robustness 171 Principle countered this problem with a simple statement, explicated 172 in [RFC7922]: "Be conservative in what you do, and liberal in what 173 you accept from others." 175 However, since this time, it has been noted that following this law 176 allows errors in protocols to accumulate over time, with overall 177 negative effects on the system as a whole. [RFC1918] describes 178 several points in conjunction with this principle that bear updating 179 based on further experience with large scale protocol and network 180 deployments within the Internet community, including: 182 o Applications should deal with error states gracefully; an 183 application should not degrade in a way that will cause the 184 failure of adjacent systems when possible. For instance, when a 185 routing protocol implementation fails, it should not do so in a 186 way that will cause the spreading of or continued existence of 187 false reachability information, nor should it fail in a way that 188 overloads adjacent routers or interacting protocols and causing a 189 cascading failure. 191 o It is best to assume the network is filled with poor 192 implementations and malevolent actors, both of which will find 193 every possible failure mode over time. 195 o It is best to assume every technology will be used to the limits 196 of its technical capabilities, rather than assuming a particular 197 protocol's scope of use will align (in any way) with the intent of 198 the original designer(s). [RFC5218] defines a wildly sucessful 199 protocol as one that "far exceeds its original goals, in terms of 200 purpose (being used in scenarios far beyond the initial design), 201 in terms of scale (being deployed on a scale much greater than 202 originally envisaged), or both." Successful implementations 203 attract more functionality, much like a few nodes in a scale free 204 graph eventually become connectivity hubs. 206 o Protocols and implementations change over time. A corollary of 207 the assumption that protocols will be used until they reach their 208 technical limits is that protocols will change over time as they 209 gain new functionality. [RFC5218] points out several problems 210 with "wild success" in a protocol: undesirable side effects, 211 performance problems, and becoming a high value attack target. 212 Protocol and implementation design should take into account use 213 cases that have not yet been thought of by building flexibility 214 into protocols. Protocols should also remained focused on a 215 narrow range of use cases; it is often wise to invent a new 216 protocol than to extend a single protocol into a broad set of use 217 cases. 219 o Protocols are sometimes replaced or updated to new versions in 220 order to add new capabilities or features. Updating a protocol 221 requires great care in providing for a transition mechanism 222 between older and newer versions. draft-iab-protocol-transitions 223 [I-D.iab-protocol-transitions] provides sound advice on protocol 224 transition planning and mehanisms. 226 o Obscure, but legal, protocol features are often ignored or left 227 unimplemented. Protocols must handle receiving unexpected 228 information gracefully so they do not fail because of incomplete 229 or partial implementations. Protocols should avoid specifying 230 contradictory states, or features that will cause interoperability 231 issues if multiple implementations choose to implement different 232 feature sets. 234 o Monocultures are almost always bad. While multiple 235 implementations can represent an interaction surface which 236 increases complexity, particularly if a brad set of protocol 237 capabilities and/or implementation features are used, using the 238 same implementation at every point in a deployment results in a 239 monoculture. In a monoculture, a single event can trigger a 240 defect in every router, causing a network failure. Monocultures 241 must be carefully balanced against interaction surfaces; often 242 this is best accomplished by using multiple implementations and 243 minimal, widely implemented, and well understood protocol 244 features. 246 A summary of the points above might be this: It is important to work 247 within the bounds of what is actually implemented in any given 248 protocol, and to leave corner cases for another day. It is often 249 easy to assume "virtual oceans" are easier to boil than physical 250 ones, or for an ocean to appear much smaller because it is being 251 implemented in software. This is often deceptive. It is never 252 helpful to boil the ocean whether in a design, an implementation, or 253 a protocol. 255 2.2. Complexity 257 Complexity, as articulated by Mike O'Dell (see [RFC3439]), is "the 258 primary mechanism which impede efficient scaling, and as a result is 259 the primary driver of increases in both capital expenditures (CAPEX) 260 and operational expenditures (OPEX)." At the same time, complexity 261 cannot be "solved," but rather must be "managed." The simplest and 262 most obvious solution to any problem is often easy to design, deploy, 263 and manage. It's also often wrong and/or broken. As much as 264 developers, designers, and operators might like to make things as 265 simple as possible, hard problems require complex solutions. See 266 Alderson and Doyle [COMPLEXHARD] for a discussion of the relationship 267 between hard problems and complex solutions. 269 The following sections contain observations which apply to the 270 management of complexity in both protocol and network design. 272 2.2.1. Elegance 274 Elegance should be the goal of protocol and network design. Rather 275 than seeking out simple solutions because they are simple, seek out 276 solutions that will solve the problem in the simplest way possible 277 (and no simpler). Often this will require: 279 o Ensuring the goal is actually the goal. Many times the goal is 280 taken from the operational realm into the protocol design realm 281 before enough thought has been applied to ensure the correct 282 problem is being addressed. 284 o Seeing the problem from different angles, trying to break the 285 problem up in multiple ways; and trying, abandoning, and 286 rebuilding ideas and implementations until a better way is found. 288 o Sometimes the complexity of the solution will overwhelm the use 289 case; sometimes it is better to leave the apparent problem 290 unsolved, or allow the community time and space to find a simpler 291 solution. 293 2.2.2. Tradeoffs 295 There are always tradeoffs. For any protocol, network, or 296 operational design decision, there will always be a tradeoff between 297 at least two competing goals. If some problem appears to have a 298 single solution without tradeoffs, this doesn't mean the tradeoffs 299 don't exist. Rather, it means the tradeoffs haven't been discovered 300 yet. In the area of protocol and network design, these tradeoffs 301 often take the form of common "choose two or three" situations, such 302 as "quick, cheap, high quality." In network and protocol design, the 303 tradeoffs are often: 305 o The amount of state carried in the system and the speed at which 306 it changes, or simply the state. The amount of state required to 307 operate a system as it scales tends to be nonlinear. Some 308 instances of this are described in [RFC3439] section 2.2.1, the 309 Amplification Principle. 311 o The number of interaction surfaces between the components that 312 make up the complete system, and the depth of those interaction 313 surfaces. Some examples of surfaces are described in 314 [RFC3439]section 2.2.2, the Coupling Principle. Layering is 315 essentially a form of abstraction; all abstractions are subject to 316 the law of leaky abstractions, [LEAKYABS] which states: "all 317 nontrivial absractions leak." 319 o The desired optimization, including efficient use of network 320 resources, optimal support for business objectives, and optimal 321 support for a specific set of applications. 323 These three make up a "triangle problem." For instance, to increase 324 the optimization of traffic flow through a network generally requires 325 adding more state to the control plane, leading to problems in 326 complexity due to amplification. To reduce amplification, the 327 control plane (or perhaps the various functions the control plane 328 serves) can be broken up into subsystems, or modules. Breaking the 329 control plane up into subsystems, however, introduces interaction 330 surfaces between the components, which is another form of complexity. 331 [RFC7980] provides a good overview of network complexity; in 332 particular, section 3 of that document provides some examples of 333 complexity tradeoffs. 335 2.3. Layered Structure 337 The Internet data plane is organized around broad top and bottom 338 layers, and much thinner middle layer. This is illustrated in the 339 figure below. 341 \ / 342 \ HTTP, FTP, SNMP, ETC. / 343 \ / 344 \ TCP, UDP / 345 \ / 346 \ IPv6 / 347 / (IPv4) \ 348 / \ 349 / (MPLS) \ 350 / Ethernet, Wireless \ 351 / Physical Media \ 352 / \ 354 Figure 1 356 This layering emulates or mirrors many naturally occurring systems; 357 it is a common strategy for managing complexity (see Meyer's 358 presentation on complexity). [COMPLEXLAYER] The single protocol in 359 the center, IPv6, serves to separate the complexity of the lower 360 layers from the complexity of the upper layers. This center layer of 361 the Internet ecosystem has traditionally been called the Network 362 Layer, in reference to the Department of Defense (DoD) [DoD] and OSI 363 models. [OSI] The Internet ecosystem includes two different 364 protocols in this central location. 366 o IPv4, an older network protocol that, it is anticipated, will be 367 replaced over time as the Internet ecosystem standardizes on IPv6 369 o IPv6, a newer network protocol that is being adopted 371 MPLS is often used as a "middle" subtransport layer, and at other 372 times as "middle" sub data link layer; hence MPLS is difficult to 373 classify within the strictly hierarchical model depicted here. These 374 protocols are often treated as if they exist in strict hierarchical 375 layers with a well defined and followed Application Programming 376 Interface (API), data models, Remote Procedure Calls (RPCs), sockets, 377 etc. The reality, however, is there are often solid reasons for 378 violating these layers, creating interaction surfaces that are often 379 deeper than intended or understood without some experience. Beyond 380 this, such layering mechanisms act as information abstractions. It 381 is well known that all such abstractions leak (see above on the law 382 of leaky abstractions). Because of these intentional and 383 unintentional leakages of information, the interactions between 384 protocols is often subtle. 386 2.4. Routers 388 A router connects to two or more logical interfaces and at least one 389 physical interface. A router processes packets by: 391 o Receiving a packet through an interface 393 o Stripping the data link, physical header, or tunnel encapsulation 394 off the packet 396 o Examining the packet for errors, and determining if this packet 397 needs to be punted to another process on the router 399 o Looking up the destination in a local forwarding table 401 o Rewriting the data link and/or physical layer header 403 o Transmitting the packet out an interface 405 When consulting the forwarding table, the router searches for a match 406 based on: 408 o The longest prefix containing the destination address (this is the 409 most common matching element) 411 o A label, such as a flow label or MPLS label 413 o The source address or other header fields (not common) 415 The router then examines the information in the matching entry to 416 determine the next hop, or rather the next logically connected device 417 to forward the packet to. The next hop will either be another 418 router, which will presumably carry the packet closer to the final 419 destination, or it will be the destination host itself. The 420 following figure provides a conceptual model of a router; not all 421 routers actually have this set of tables and interactions, and some 422 have many more moving parts. This model is simply used as a common 423 reference to promote understanding. 425 +-------------+ +-------------+ 426 | Candidate | | Startup | 427 | Config |<--+ +-->| Config | 428 +--+----------+ | | +-------+-----+ 429 | | | | 430 v | | v 431 +-----------------+----+-----------------+ 432 | Running Configuration +------>----------+ 433 +---+----------+----------+----------+---+ | 434 | | | | | 435 v | | | | 436 +-------+ | | | | 437 | IS-IS |<-----------------------------------> Adjacent | 438 +---+---+ v | | Routers | 439 | +-------+ | | | 440 | | BGP |<------------------------> Peers | 441 | +---+---+ v | | 442 | | +-------+ | | 443 | | | OSPF |<-------------> Adjacent | 444 | | +---+---+ v Routers | 445 | | | +-------+ | 446 | | | | Other | | 447 | | | +---+---+ | 448 | | | | | 449 +---+----------+----------+----------+---+ | 450 | RIB Manager | | 451 +---+------------------------------------+ | 452 | | 453 +---+------------------------------------+ | 454 | Routing Information Base (RIB) | | 455 +---+------------------------------------+ | 456 | | 457 +---+------------------------------------+ | 458 | Forwarding Information Base (FIB) | | 459 +---+----------+---------------------+---+ | 460 | | | | 461 +---+---+ +---+---+ +---+---+ | 462 | Int 1 | | Int 2 | ... | Int X | <---------------+ 463 +-------+ +-------+ +-------+ 464 ^ | 465 | v 466 Packets In Packets Out 468 Figure 2 470 3. Requirements Related to Device Management and Security 472 Network engineering began in the era of Command Line Interfaces 473 (CLIs), and has generally stayed with these CLIs even as the 474 Graphical User Interface (GUI) has become the standard way of 475 interacting with almost every other computing device. Direct human 476 interaction with routers and middleboxes in large scale and complex 477 environments, however, tends to result in an unacceptably low Mean 478 Time Between Mistakes (MTBM), directly impacting the overall 479 availability of the network. In reaction to this, operators have 480 increased their reliance on automation, specifically targetting 481 machine to machine intefaces, such as Remote Procesdure Calls (RPCs) 482 and Application Programming Interface (API) solutions, to manage and 483 configure routers and middleboxes. This section considers the 484 various components of device management. 486 3.1. Programmable Device Access 488 Configuration primarily relates to the startup, candidate, and 489 running configurations in the router model shown above. In order to 490 deploy networks at scale, operators rely on automated management of 491 router configuration. This effort has traditionally focused on 492 Simple Network Management Protocol (SNMP) Management Information Base 493 (MIBs). In the future, operators expect to move towards open source/ 494 open standards YANG models. 496 Vendors and implementors should implement machine readable interfaces 497 with overlays to support human interaction, rather than human 498 readable interfaces with overlays to support machine to machine 499 interaction. Emphasis should be placed on machine to machine 500 interaction for day to day operations, rather than on human readable 501 interfaces, which are largely used in the process of troubleshooting. 502 Within the realm of machine to machine interfaces, emphasis should be 503 placed on marshaling information in YANG models. 505 To support automated router configuration, IPv6 routers and routers 506 SHOULD support YANG and SNMP configuration, including (but not 507 limited to): 509 o Openconfig models [OPENCONF] related to the protocols configured 510 on the device, interface state, and device state 512 o [RFC7223]: A YANG Data Model for Interface Management 514 o [RFC7224]: IANA Interface Type YANG Module 516 o [RFC7277]: A YANG Data Model for IP Management 517 o [RFC7317]: A YANG Data Model for System Management 519 o Simple Network Management Protocol (SNMP) MIBs as appropriate 521 3.2. Human Readable Device Access 523 To operate a network at scale, operators rely on the ability to 524 access routers and middleboxes to troubleshoot and gather state 525 manually through a number of different interfaces. These interfaces 526 should provide current device configuration, current device state 527 (such as interface state, packets drops, etc.), and current control 528 plane contents (such as the RIB in the figure above). In other 529 words, manual interfaces should provide information about the router 530 (the whole device stack). 532 To support manual state gathering and troubleshooting, IPv6 routers 533 and middleboxes SHOULD support: 535 o TELNET ([RFC0854]): TELNET SHOULD be disabled by default, but 536 should be available for operational purposes as required or as 537 configured by the operator 539 o SSH ([RFC4253]): SSH SHOULD be the default access for IPv6 capable 540 routers 542 3.3. Zero Touch Provisioning 544 To operate a network at scale, operators rely on protocols and 545 mechanisms that reduce provisioning time to a minimum. The preferred 546 state is zero touch provisioning; plug a new router in and it just 547 works without any manual configuration. The closer an operator can 548 come to this ideal, the more MTBM and Operational Expenses (OPEX) can 549 be reduced -- an important goals in the real world. IPv6 routers 550 should support several standards, including, but not limited to: 552 o [I-D.ietf-dhc-rfc3315bis]: Dynamic Configuration Protocol for IPv6 554 o SLAAC ([RFC7217] and [RFC7527]): SLAAC SHOULD be enabled by 555 default on all router interfaces 557 SLAAC SHOULD be able to be disabled by operators who prefer to use 558 some other mechanism for address management and assignment. 560 3.4. Authentication, Authorization, and Accounting 562 (Need some text here) 564 3.5. Device Protection against Denial of Service Attacks 566 Denial of Service (DoS) and Distributed Denial of Service (DDoS) 567 attacks are unfortunately common in the Internet globally; these 568 types of attacks cost network operators a great deal in opportunity 569 and operational costs in prevention and responses. To provide for 570 effective counters to DoS and DDoS attacks directly on routers: 572 o Manufacturers and system integrators should test and clearly 573 report the packet/traffic load handling capabilities of devices 574 with and without various encryption methods enabled 576 o Routers should be able to police traffic destined to the control 577 plane based on the rate of traffic received, including the ability 578 ot police individual flows, targeted services, etc., at individual 579 rates as described in [RFC6192] 581 o Ideally, devices should be able to statefully filter traffic 582 destined to the control plane 584 There are other useful techniques for dealing with DDoS attacks at 585 the network level, including: transferring sessions to a new address 586 and abandoning the address under attack, using BGP communities to 587 spread the attack over multiple ingress ports and "consume" it, and 588 requiring mutual authentication before allocating larger resource 589 pools to a connection. These techniques are not "device level," and 590 hence are not considered further here. 592 4. Requirements Related to Telemetry 594 Telemetry relates to information devices push to systems used to 595 monitor and track the state of the network. This applies to 596 individual devices as well as the network as a system. Two major 597 challenges face operators in the area of telemetry: 599 o Information that is laid out primarily for human, rather than 600 machine, consumption. While human consumption of telemetry is 601 important in some situations, this information should be supplied 602 in a form that focuses on machine readability with an overlay or 603 interpretor that allows human consumption. 605 o Software systems that require information to be queried (or polled 606 or even pushed) on a per-item basis. This form of organization 607 can produce a lot of information, and a lot of individual packets, 608 very quickly, overwhelming monitoring systems and consuming a 609 large amount of available network resources. Instead, telemetry 610 should be focused on bulk collection. 612 There are three broad categories of telemetry: device state and 613 traceability, topology state and traceability, and flow traceability. 614 These three roughly correspond to the management plane, the control 615 plane, and the forwarding plane of the network. Each of the sections 616 below considers one of these three telemetry types. 618 4.1. Device State and Traceablity 620 Ideally, the entire network could be monitored using a single 621 modeling language to ease implementation of telemetry systems and 622 increase the pace at which new software can be deployed in production 623 environments. In real deployments, it is often impossible to reach 624 this ideal; however, reducing the languages and methods used, while 625 focusing on machine readibility, can greatly ease the deployment and 626 management of a large scale network. Specifically, IPv6 routers 627 SHOULD support: 629 o [RFC6241]: NETCONF/RESTCONF transporting telemetry formatted 630 according to YANG (see above) 632 o [RFC5424]: Syslog 634 o gRPC based telemetry interfaces [GRPC] 636 o SNMP as appropriate 638 Syslog and SNMP access for telemetry should be considered "legacy," 639 and should not be the focus of new telemetry access development 640 efforts. 642 4.2. Topology State and Traceability 644 IPv6 routers are part of a system of devices that, combined, make up 645 the entire network. Viewing the network as a system is often crucial 646 for operational purposes. For instance, being able to understand 647 changes in the topology and utlization of a network can lead to 648 insights about traffic flow and network growth that lead to a greater 649 understanding of how the network is operating, where problems are 650 developing, and how to improve the network's performance. To support 651 systemic monitoring of the network topology, IPv6 devices SHOULD 652 support at least: 654 o [RFC5424]: North-Bound Distribution of Link-State and Traffic 655 Engineering (TE) Information using BGP 657 o [I-D.ietf-i2rs-yang-l2-network-topology]: An I2RS model for layer 658 2 topologies 660 o [I-D.ietf-i2rs-yang-l3-topology]: An I2RS model for layer 3 661 topologies 663 o [I-D.ietf-i2rs-yang-network-topo]: A Data Model for Network 664 Topologies 666 4.3. Flow Traceability 668 (To be added) 670 5. Requirements Related to IPv6 Forwarding and Addressing 672 There are a number of capabilities that a device SHOULD have to be 673 deployed into an IPv6 network, and several forwarding plane 674 considerations operators and vendors need to bear in mind. The 675 sections below explain these considerations. 677 5.1. The IPv6 Address is not a Host Identifier 679 The IPv6 address is commonly treated as a host identifier; it is not. 680 Rather, it is an interface identifier that describes the topological 681 point where a particular host connects to the Internet. 682 Specifically: 684 o The IPv6 address will change when a device changes where it 685 connects to the network. 687 o A single host can have multiple addresses. For instance, a host 688 may have one address per interface, or multiple addresses assigned 689 through different mechanisms, or through multiple connection 690 points. 692 o A single IPv6 address may represent many hosts, as in the case of 693 a group of hosts reachable through multicast address, or a set of 694 services reachable through an anycast address. 696 Because the host address may change at any time, it is generally 697 harmful to embed IPv6 addresses inside upper layer headers to 698 identify a particular host. 700 5.2. Router Handling of IPv6 Addresses 702 Internet Routing Registries may allocate a network operator a wide 703 range of prefix lengths (see [RFC6177] for further information). 704 Within this allocation, network operators will often suballocate 705 address space along nibble boundaries (/48, /52, /56, /60, and /64) 706 for ease of configuration and management. Several common practices 707 are: 709 o Each multiaccess interface is allocated a /64 711 o Point-to-point links are allocated a /64, but SHOULD be addressed 712 with a longer prefix length to prevent certain kinds of denial of 713 service attacks ([RFC3627] originally mandated 64 bit prefix 714 lengths on point-to-point links; [RFC6164] explains possible 715 security issues with assigning a 64 bit prefix length to a point- 716 to-point, and recommends a /127 instead) 718 o Although aggregation may only performed to the nibble boundaries 719 noted above, variances are possible 721 o Loopback addresses are assigned a /128 723 Given these common practices, routers designed to run IPv6 SHOULD 724 support the following addressing conventions: 726 o The default prefix length on any interface other than a loopback 727 SHOULD be a /64 729 o Configuring a prefix length longer than a /64 on any multi-access 730 interface should require additional configuration steps to prevent 731 manual configuration errors 733 o Routers SHOULD NOT assume IPv6 prefix lengths only on nibble 734 boundaries 736 o Routers SHOULD support any prefix length shorter or greater than 737 /64 739 o Loopback interfaces SHOULD default to a /128 prefix length unless 740 some additional configuration is undertaken to override this 741 default setting 743 5.3. Maximum Transmission Unit and Jumbo Frames 745 The long history of the Maximum Transmission Unit (MTU) in networks 746 is not a happy one. Specific problems with MTU sizing include: 748 o Many different default sizes on different media types, from very 749 small (576 bytes on X.25) to very large (17914 bytes on 16Mbps 750 Token Ring) 752 o Many different ways to calcualte the MTU on any given link; for 753 instance a 9000 byte MTU can be calculated as 8184 bytes on one 754 operating system, 8972 on another, and 9000 on a third 756 o The increasing use of tunnel encapsulations in the network; for 757 instance MPLS over GRE over IP over... 759 o The wide variety of default MTUs across many different end hosts 760 and operating systems 762 o The general ineffectiveness of path MTU discovery to operate 763 correctly in the face of packet filters and rate limiters (see the 764 section on ICMP filtering below) 766 o Lower speed links at the network edge which require a lot of time 767 to serialize a packet with a large MTU 769 o Increased jitter caused by the disparity between large and small 770 packet size across a lower bandwidth links 772 The final point requires some further elucidation. The time required 773 to serialize various packets at various speeds are: 775 o 64 byte packet onto a 10Mb/s link: .5ms 777 o 1500 byte packet onto a 10Mb/s link: 1.2ms 779 o 9000 byte packet onto a 10Mb/s link: 7.2ms 781 o 64 byte packet onto a 100Mb/s link: .05ms 783 o 1500 byte packet onto a 100Mb/s link: .12ms 785 o 9000 byte packet onto a 100Mb/s link: .72ms 787 A 64 byte packet trapped behind a single 1500 byte packet on a 10Mb/s 788 link suffers 1.2ms of serialization delay. Each additional 1500 byte 789 packet added to the queue in front of the 64 byte packet adds and 790 addtional 1.2ms of delay. In contrast, a 64 byte packet trapped 791 behind a single 9000 byte packet on a 10Mb/s link suffers 7.7ms of 792 serialization delay. Each additional 9000 byte packet added to the 793 queue adds an additional 7.2ms of serialization delay. The practical 794 result is that larger MTU sizes on lower speed links can add a 795 significant amount of delay and jitter into a flow. On the other 796 hand, increasing the MTU on higher speed links appears to add 797 megligable additional delay and jitter. 799 The result is that it costs less in terms of overall systemic 800 performance to use higher MTUs on higher speed links than on lower 801 speed links. Based on this, increasing the MTU across any particular 802 link may not increase overall end-to-end performance, but can greatly 803 enhance the performance of local applications (such as a local BGP 804 peering session, or a large/long standing elephant flow used to 805 transfer data across a local fabric), while also providing room for 806 tunnel encapsulations to be added with less impact on lower MTU end 807 systems. 809 The general rule of thumb is to assume the largest size MTU should be 810 used on higher speed transit only links in order to support a wide 811 array of available link sizes, default MTUs, and tunnel 812 encapsulations. Routers designed for a network or data center core 813 SHOULD support at least 9000 byte MTUs on all interfaces. MTU 814 detection mechanisms, such as IS-IS hello padding, described in 815 [RFC7922], SHOULD be enabled to ensure correct point-to-point MTU 816 configuration. Devices SHOULD also support: 818 o [RFC1191]: Path MTU Discovery 820 o [RFC1981]: Path MTU Discovery for IP version 6 822 o [RFC4821]: Packetization Layer Path MTU Discovery 824 5.4. ICMP Considerations 826 Internet Control Message Protocool (ICMP) is described in [RFC0792] 827 and [RFC4443]. ICMP is often used to perform a traceroute through a 828 network (normally by using a TTL expired ICMP message), for Path MTU 829 discovery, and, in IPv6, for autoconfiguration and neighbor 830 discovery. ICMP is often blocked by middleboxes of various kinds 831 and/or ICMP filters configured on the ingress edge of a provider 832 network, most often to prevent the discovery of reachable hosts and 833 network topology. Routers implementing IPv6: 835 o SHOULD NOT filter ICMP unreachables by default, as this has 836 negative impacts on many aspects of IPv6 operation, particularly 837 path MTU 839 o SHOULD filter ICMP echo and echo response by default, to prevent 840 the discovery of reachable hosts and topology. 842 o SHOULD rate limit the generation of ICMP messages relative to the 843 ability of the device to generate packets and to block the use of 844 ICMP packets being used as part of a distributed denial of service 845 attack 847 o SHOULD implement the filtering suggestions in 848 [I-D.gont-opsec-icmp-ingress-filtering] 850 There are implications for path MTU discovery and other useful 851 mechanisms in filtering and rate limiting ICMP. The tradeoff here is 852 between allowing unlimited ICMP, which would allow path MTU detection 853 to work, or limiting ICMP in a way that prevents negative side 854 effects for individual devices, and hence the operational 855 capabilities of the network as a whole. Operators rightly limit ICMP 856 to reduce the attack surface against their network, as well as the 857 opportinity for "perfect storm" events that inadvertently reduce the 858 capability of routers and middleboxes. Hence ICMP can be treated as 859 "quasi-reliable" in many situations; existence of an ICMP message can 860 prove, for instance, that a particular host is unreachable. The non- 861 existence of an ICMP message, however, does not prove a particular 862 host exists or does not. 864 5.5. Machine Access to the Forwarding Table 866 In order to support treating the "network as a whole" as a single 867 programmable system, it is important for each router have the ability 868 to directly program forwarding information. This programmatic 869 interface allows controllers, which are programmed to support 870 specific business logic and applications, to modify and filter 871 traffic flows without interfering with the distributed control plane. 872 While there are several programmatic interfaces available, this 873 document suggests that the I2RS interface to the RIB be supported in 874 all IPv6 routers. Specifically, these drafts should be supported to 875 enable network programmability: 877 o [I-D.ietf-i2rs-fb-rib-data-model]: Filter-Based RIB Data Model 879 o [I-D.ietf-i2rs-fb-rib-info-model]: Filter-Based RIB Information 880 Model 882 o [I-D.ietf-i2rs-rib-data-model]: A YANG Data Model for Routing 883 Information Base (RIB) 885 o [RFC7922]: I2RS Traceability 887 5.6. Processing IPv6 Extension Headers 889 (To be added) 891 5.7. IPv6 Only Operation 893 While the transition to IPv6 only networks may take years (or perhaps 894 decades), a number of operators are moving to deploy IPv6 on internal 895 networks supporting transport and data center fabric applications 896 more quickly. Routers and middleboxes that support IPv6 SHOULD 897 support IPv6 only operation, including: 899 o Link Local addressing SHOULD be configurable and useable as the 900 primary address on all interfaces on a device. 902 o IPv4 and/or MPLS SHOULD NOT be required for proper device 903 operation. For instance, an IPv4 address should not be required 904 to determine the router ID for any protocol. See [RFC6540] 905 section 2. 907 o Any control plane protocol implementations SHOULD support the 908 recommendations in [RFC7404] for operation using link local 909 addresses only. 911 6. Future Considerations 913 (To be added) 915 6.1. Segment Routing 917 (To be added) 919 7. Security Considerations 921 This document addresses several ways in which devices designed to 922 support IPv6 forwarding. Some of the recommendations here are 923 designed to increase device security; for instance, see the section 924 on device access. Others may intersect with security, but are not 925 specifically targeted at security, such as running IPv6 link local 926 only on links. These are not discussed further here, as they improve 927 the security stance of the network. Other areas discussed in this 928 draft are more nuanced. This section gathers the intersection 929 between operational concerns and security concerns into one place. 931 ICMP security is already considered in the section on ICMP; it will 932 not be considered further here. Link local only addressing wil 933 increase security by removing transit only links within the network 934 as a reachable destination. 936 7.1. Robustness and Security 938 Robustness, particularly in the area of error handling, largely 939 improves security if designed and implemented correctly. Many 940 attacks take advantage of mistakes in implementations and variations 941 in protocols. In particular, any feature that is unevenly 942 implemented among a number of implementations often offers an attack 943 surface. Hence, reducing protocol complexity helps reduce the 944 breadth of attack surfaces. 946 Another point to consider at the intersection of robustness and 947 security is the issue of monocultures. Monocultures are in and of 948 themselves a potential attack surface, in that finding a single 949 failure mode can be exploited to take an entire network (or operator) 950 down. On the other hand, reducing the number of implementations for 951 any particular protocol will decrease the set of "random" features 952 deployed in the network. These two goals will often be opposed to 953 one another. Network designers and operators need to consider these 954 two sides of this tradeoff, and make an intelligent decision about 955 how much diversity to implement versus how to control the attack 956 surface represented by deploying a wide array of implementations. 958 7.2. Programmable Device Access and Security 960 Programmable interfaces, including programmable configuration, 961 telemetry, and machine interface to the routing table, introduce a 962 large attack surface; operators should be careful to ensure this 963 attack surface is properly secured. Specifically: 965 o Prevent external access to any administrative access points used 966 for device programmability 968 o Use AAA systems to ensure only valid devices and/or users access 969 devices 971 o Rate limit the change rate and protect management interfaces from 972 DoS and DDoS attacks 974 Such interfaces should be treated no differently than SSH, SFTP, and 975 other interfaces available to manage routers and middleboxes. 977 7.3. Zero Touch Provisioning and Security 979 Zero touch provisioning opens a new attack surface; insider attackers 980 can simply install a new device, and assume it will be autoconfigured 981 into the network. A "simple" solution would be to install door 982 locks, but this will likely not be enough; defenses need to be 983 layered to be effective. It is recommended that devices installed in 984 the network need to contain a hardware or software identification 985 system that allows the operator to identify devices that are 986 installed in the network. 988 8. Conclusion 990 The deployment of IPv6 throughout the Internet marks a point in time 991 where it is good to review the overall Internet architecture, and 992 assess the impact on operations of these changes. This document 993 provides an overview of a lot of these changes and lessons learned, 994 as well as providing pointers to many of the relevant documents to 995 understand each topic more deeply. 997 9. References 999 9.1. Normative References 1001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1002 Requirement Levels", BCP 14, RFC 2119, 1003 DOI 10.17487/RFC2119, March 1997, 1004 . 1006 9.2. Informative References 1008 [COMPLEXHARD] 1009 Alderson, D. and J. Doyle, "Contrasting Views of 1010 Complexity and Their Implications For Network-Centric 1011 Infrastructures", 2010, 1012 . 1015 [COMPLEXLAYER] 1016 Meyer, D., "Macro Trends, Architecture, and the Hidden 1017 Nature of Complexity", 2010, 1018 . 1021 [DoD] Wikipedia, "The Internet Protocol Suite", 2016, 1022 . 1024 [GRPC] gRPC, "gRPC", 2016, . 1026 [I-D.gont-opsec-icmp-ingress-filtering] 1027 Gont, F., Hunter, R., Massar, J., and S. LIU, "Defeating 1028 Attacks which employ Forged ICMP/ICMPv6 Error Messages", 1029 draft-gont-opsec-icmp-ingress-filtering-02 (work in 1030 progress), March 2016. 1032 [I-D.iab-protocol-transitions] 1033 Thaler, D., "Out With the Old and In With the New: 1034 Planning for Protocol Transitions", draft-iab-protocol- 1035 transitions-05 (work in progress), January 2017. 1037 [I-D.ietf-dhc-rfc3315bis] 1038 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1039 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1040 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 1041 bis", draft-ietf-dhc-rfc3315bis-06 (work in progress), 1042 October 2016. 1044 [I-D.ietf-i2rs-fb-rib-data-model] 1045 Hares, S., Kini, S., Dunbar, L., Krishnan, R., Bogdanovic, 1046 D., and R. White, "Filter-Based RIB Data Model", draft- 1047 ietf-i2rs-fb-rib-data-model-00 (work in progress), June 1048 2016. 1050 [I-D.ietf-i2rs-fb-rib-info-model] 1051 Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, 1052 R., Bogdanovic, D., and R. White, "Filter-Based RIB 1053 Information Model", draft-ietf-i2rs-fb-rib-info-model-00 1054 (work in progress), June 2016. 1056 [I-D.ietf-i2rs-rib-data-model] 1057 Wang, L., Ananthakrishnan, H., Chen, M., 1058 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 1059 YANG Data Model for Routing Information Base (RIB)", 1060 draft-ietf-i2rs-rib-data-model-07 (work in progress), 1061 January 2017. 1063 [I-D.ietf-i2rs-yang-l2-network-topology] 1064 Dong, J. and X. Wei, "A YANG Data Model for Layer-2 1065 Network Topologies", draft-ietf-i2rs-yang-l2-network- 1066 topology-03 (work in progress), July 2016. 1068 [I-D.ietf-i2rs-yang-l3-topology] 1069 Clemm, A., Medved, J., Varga, R., Liu, X., 1070 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1071 for Layer 3 Topologies", draft-ietf-i2rs-yang- 1072 l3-topology-08 (work in progress), January 2017. 1074 [I-D.ietf-i2rs-yang-network-topo] 1075 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1076 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1077 Topologies", draft-ietf-i2rs-yang-network-topo-11 (work in 1078 progress), February 2017. 1080 [I-D.ietf-netconf-restconf] 1081 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1082 Protocol", draft-ietf-netconf-restconf-18 (work in 1083 progress), October 2016. 1085 [LEAKYABS] 1086 Spolsky, J., "The Law of Leaky Abstractions", 2002, 1087 . 1090 [OPENCONF] 1091 OpenConfig, "Openconfig release YANG models", 2016, 1092 . 1095 [OSI] Wikipedia, "OSI Model", 2016, 1096 . 1098 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1099 RFC 792, DOI 10.17487/RFC0792, September 1981, 1100 . 1102 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 1103 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1104 1983, . 1106 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1107 DOI 10.17487/RFC1191, November 1990, 1108 . 1110 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 1111 RFC 1812, DOI 10.17487/RFC1812, June 1995, 1112 . 1114 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1115 and E. Lear, "Address Allocation for Private Internets", 1116 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1117 . 1119 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1120 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1121 1996, . 1123 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1124 DOI 10.17487/RFC2629, June 1999, 1125 . 1127 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 1128 Guidelines and Philosophy", RFC 3439, 1129 DOI 10.17487/RFC3439, December 2002, 1130 . 1132 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1133 Text on Security Considerations", BCP 72, RFC 3552, 1134 DOI 10.17487/RFC3552, July 2003, 1135 . 1137 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 1138 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 1139 September 2003, . 1141 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1142 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1143 January 2006, . 1145 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1146 Control Message Protocol (ICMPv6) for the Internet 1147 Protocol Version 6 (IPv6) Specification", RFC 4443, 1148 DOI 10.17487/RFC4443, March 2006, 1149 . 1151 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1152 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1153 . 1155 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 1156 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1157 . 1159 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 1160 DOI 10.17487/RFC5424, March 2009, 1161 . 1163 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1164 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1165 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 1166 . 1168 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1169 Assignment to End Sites", BCP 157, RFC 6177, 1170 DOI 10.17487/RFC6177, March 2011, 1171 . 1173 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1174 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1175 March 2011, . 1177 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1178 and A. Bierman, Ed., "Network Configuration Protocol 1179 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1180 . 1182 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1183 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1184 RFC 6540, DOI 10.17487/RFC6540, April 2012, 1185 . 1187 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1188 Interface Identifiers with IPv6 Stateless Address 1189 Autoconfiguration (SLAAC)", RFC 7217, 1190 DOI 10.17487/RFC7217, April 2014, 1191 . 1193 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1194 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1195 . 1197 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1198 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1199 . 1201 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1202 RFC 7277, DOI 10.17487/RFC7277, June 2014, 1203 . 1205 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1206 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1207 2014, . 1209 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 1210 Addressing inside an IPv6 Network", RFC 7404, 1211 DOI 10.17487/RFC7404, November 2014, 1212 . 1214 [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., 1215 and W. George, "Enhanced Duplicate Address Detection", 1216 RFC 7527, DOI 10.17487/RFC7527, April 2015, 1217 . 1219 [RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the 1220 IAB Workshop on Stack Evolution in a Middlebox Internet 1221 (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, 1222 . 1224 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1225 the Routing System (I2RS) Traceability: Framework and 1226 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 1227 2016, . 1229 [RFC7980] Behringer, M., Retana, A., White, R., and G. Huston, "A 1230 Framework for Defining Network Complexity", RFC 7980, 1231 DOI 10.17487/RFC7980, October 2016, 1232 . 1234 Authors' Addresses 1236 Zaid Ali Kahn, Editor 1237 LinkedIn 1238 xxx 1239 xxx, CA xxx 1240 USA 1242 Email: zaid@linkedin.com 1244 John Brzozowski, Editor 1245 Comcast 1246 xxx 1247 xxx, xxx xxx 1248 USA 1250 Email: John_Brzozowski@comcast.com 1252 Russ White, Editor 1253 LinkedIn 1254 Oak Island, NC 28465 1255 USA 1257 Email: russ@riw.us