idnits 2.17.1 draft-ietf-v6ops-ipv6rtr-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 1304 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 (May 5, 2017) is 2549 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-restconf' is defined on line 1107, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1146, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1155, 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 (-13) exists of draft-ietf-dhc-rfc3315bis-07 == 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-12 -- 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 6434 (Obsoleted by RFC 8504) -- 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 (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Kahn, Ed. 3 Internet-Draft LinkedIn 4 Intended status: Informational J. Brzozowski, Ed. 5 Expires: November 6, 2017 Comcast 6 R. White, Ed. 7 LinkedIn 8 May 5, 2017 10 Requirements for IPv6 Routers 11 draft-ietf-v6ops-ipv6rtr-reqs-00 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 November 6, 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. Supporting Zero Touch Provisioning for Connected Devices 12 82 3.4. Device Protection against Denial of Service Attacks . . . 13 83 4. Requirements Related to Telemetry . . . . . . . . . . . . . . 14 84 4.1. Device State and Traceablity . . . . . . . . . . . . . . 14 85 4.2. Topology State and Traceability . . . . . . . . . . . . . 15 86 5. Requirements Related to IPv6 Forwarding and Addressing . . . 15 87 5.1. The IPv6 Address is not a Host Identifier . . . . . . . . 16 88 5.2. Router IPv6 Addresseses . . . . . . . . . . . . . . . . . 16 89 5.3. The Maximum Transmission Unit . . . . . . . . . . . . . . 17 90 5.4. ICMP Considerations . . . . . . . . . . . . . . . . . . . 19 91 5.5. Machine Access to the Forwarding Table . . . . . . . . . 20 92 5.6. Processing IPv6 Extension Headers . . . . . . . . . . . . 20 93 5.7. IPv6 Only Operation . . . . . . . . . . . . . . . . . . . 20 94 5.8. Prefix Length Handling in IPv6 PAcket Forwarding . . . . 21 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 96 6.1. Robustness and Security . . . . . . . . . . . . . . . . . 21 97 6.2. Programmable Device Access and Security . . . . . . . . . 22 98 6.3. Zero Touch Provisioning and Security . . . . . . . . . . 22 99 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 102 8.2. Informative References . . . . . . . . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 105 1. Introduction 107 This memo defines and discusses requirements for devices that perform 108 forwarding for Internet Protocol version 6 (IPv6). This can include 109 (but is not limited to) the devices described below. 111 o Devices which are primarily designed to forward traffic between 112 multiple interfaces. These are normally referred to by the 113 Internet community as routers or, in some cases, intermediate 114 systems. 116 o Devices which are designed to modify packets rather than "just" 117 forwarding them. These are often referred to by the Internet 118 community as middleboxes. See [RFC7663] for a fuller definition 119 of middleboxes. 121 Readers should recognize that while this memo applies to IPv6, 122 routers and middleboxes IPv6 packets will often also process IPv4 123 packets, forward based on MPLS labels, and potentially process many 124 other protocols. This memo will only discuss IPv4, MPLS, and other 125 protocols as they impact the behavior of an IPv6 forwarding device; 126 no attempt is made to specify requirements for protocols other than 127 IPv6. The reader should, therefore, not count on this document as a 128 "sole source of truth," but rather use this document as a guide. 130 For IPv4 router requirements, readers are referred to [RFC1812]. For 131 simplicity, the term "devices" is used interchangeably with the 132 phrase "routers and middleboxes" and the term "routers" throughout 133 this document. These three terms represent stylistic differences, 134 rather than substantive differences. 136 This document is broken into the following sections: a review of 137 Internet architecture and principles, requirements relating to device 138 management, requirements related to telemetry, requirements related 139 to IPv6 forwarding and addressing, and future considerations. 140 Following these sections, a short conclusion is provided for review. 142 1.1. Contributors 144 Shawn Zandi, Pete Lumbis, Fred Baker, and Lee Howard contributed 145 significant text and ideas to this draft. 147 1.2. Acknowledgements 149 The editors and contributors would like to thank Ron Bonica, Lorenzo 150 Coitti, Brian E. Carpenter, Tim Chown, Peter Lothberg, and ... for 151 their comments, edits, and ideas on the text of this draft. 153 2. Review of the Internet Architecture 155 The Internet relies on a number of basic concepts and considerations. 156 These concepts are not explicitly called out in any specification, 157 nor do they necessarily impact protocol design or packet forwarding 158 directly. This section provides an overview of these concepts and 159 considerations to help the reader understand the larger context of 160 this document. 162 2.1. Robustness Principle 164 Every point where multiple protocols interact, is an interaction 165 surface that can threaten the robustness of the overall system. 166 While it may seem the global Internet has achieved a level of 167 stability that makes it immune to such considerations, the reality is 168 every network is a complex system, and is therefore subject to 169 massive non repeatable unanticipated failures. Postel's Robustness 170 Principle countered this problem with a simple statement, explicated 171 in [RFC7922]: "Be conservative in what you do, and liberal in what 172 you accept from others." 174 However, since this time, it has been noted that following this law 175 allows errors in protocols to accumulate over time, with overall 176 negative effects on the system as a whole. [RFC1918] describes 177 several points in conjunction with this principle that bear updating 178 based on further experience with large scale protocol and network 179 deployments within the Internet community, including: 181 o Applications should deal with error states gracefully; an 182 application should not degrade in a way that will cause the 183 failure of adjacent systems when possible. For instance, when a 184 routing protocol implementation fails, it should not do so in a 185 way that will cause the spreading of or continued existence of 186 false reachability information, nor should it fail in a way that 187 overloads adjacent routers or interacting protocols and causing a 188 cascading failure. 190 o It is best to assume the network is filled with poor 191 implementations and malevolent actors, both of which will find 192 every possible failure mode over time. 194 o It is best to assume every technology will be used to the limits 195 of its technical capabilities, rather than assuming a particular 196 protocol's scope of use will align (in any way) with the intent of 197 the original designer(s). [RFC5218] defines a wildly sucessful 198 protocol as one that "far exceeds its original goals, in terms of 199 purpose (being used in scenarios far beyond the initial design), 200 in terms of scale (being deployed on a scale much greater than 201 originally envisaged), or both." Successful implementations 202 attract more functionality, much like a few nodes in a scale free 203 graph eventually become connectivity hubs. 205 o Protocols and implementations change over time. A corollary of 206 the assumption that protocols will be used until they reach their 207 technical limits is that protocols will change over time as they 208 gain new functionality. [RFC5218] points out several problems 209 with "wild success" in a protocol: undesirable side effects, 210 performance problems, and becoming a high value attack target. 211 Protocol and implementation design should take into account use 212 cases that have not yet been thought of by building flexibility 213 into protocols. Protocols should also remained focused on a 214 narrow range of use cases; it is often wise to invent a new 215 protocol than to extend a single protocol into a broad set of use 216 cases. 218 o Protocols are sometimes replaced or updated to new versions in 219 order to add new capabilities or features. Updating a protocol 220 requires great care in providing for a transition mechanism 221 between older and newer versions. draft-iab-protocol-transitions 222 [I-D.iab-protocol-transitions] provides sound advice on protocol 223 transition planning and mehanisms. 225 o Obscure, but legal, protocol features are often ignored or left 226 unimplemented. Protocols must handle receiving unexpected 227 information gracefully so they do not fail because of incomplete 228 or partial implementations. Protocols should avoid specifying 229 contradictory states, or features that will cause interoperability 230 issues if multiple implementations choose to implement different 231 feature sets. 233 o Monocultures are almost always bad. While multiple 234 implementations can represent an interaction surface which 235 increases complexity, particularly if a brad set of protocol 236 capabilities and/or implementation features are used, using the 237 same implementation at every point in a deployment results in a 238 monoculture. In a monoculture, a single event can trigger a 239 defect in every router, causing a network failure. Monocultures 240 must be carefully balanced against interaction surfaces; often 241 this is best accomplished by using multiple implementations and 242 minimal, widely implemented, and well understood protocol 243 features. 245 A summary of the points above might be this: It is important to work 246 within the bounds of what is actually implemented in any given 247 protocol, and to leave corner cases for another day. It is often 248 easy to assume "virtual oceans" are easier to boil than physical 249 ones, or for an ocean to appear much smaller because it is being 250 implemented in software. This is often deceptive. It is never 251 helpful to boil the ocean whether in a design, an implementation, or 252 a protocol. 254 2.2. Complexity 256 Complexity, as articulated by Mike O'Dell (see [RFC3439]), is "the 257 primary mechanism which impede efficient scaling, and as a result is 258 the primary driver of increases in both capital expenditures (CAPEX) 259 and operational expenditures (OPEX)." At the same time, complexity 260 cannot be "solved," but rather must be "managed." The simplest and 261 most obvious solution to any problem is often easy to design, deploy, 262 and manage. It's also often wrong and/or broken. As much as 263 developers, designers, and operators might like to make things as 264 simple as possible, hard problems require complex solutions. See 265 Alderson and Doyle [COMPLEXHARD] for a discussion of the relationship 266 between hard problems and complex solutions. 268 The following sections contain observations which apply to the 269 management of complexity in both protocol and network design. 271 2.2.1. Elegance 273 Elegance should be the goal of protocol and network design. Rather 274 than seeking out simple solutions because they are simple, seek out 275 solutions that will solve the problem in the simplest way possible 276 (and no simpler). Often this will require: 278 o Ensuring the goal is actually the goal. Many times the goal is 279 taken from the operational realm into the protocol design realm 280 before enough thought has been applied to ensure the correct 281 problem is being addressed. 283 o Seeing the problem from different angles, trying to break the 284 problem up in multiple ways; and trying, abandoning, and 285 rebuilding ideas and implementations until a better way is found. 287 o Sometimes the complexity of the solution will overwhelm the use 288 case; sometimes it is better to leave the apparent problem 289 unsolved, or allow the community time and space to find a simpler 290 solution. 292 2.2.2. Tradeoffs 294 There are always tradeoffs. For any protocol, network, or 295 operational design decision, there will always be a tradeoff between 296 at least two competing goals. If some problem appears to have a 297 single solution without tradeoffs, this doesn't mean the tradeoffs 298 don't exist. Rather, it means the tradeoffs haven't been discovered 299 yet. In the area of protocol and network design, these tradeoffs 300 often take the form of common "choose two or three" situations, such 301 as "quick, cheap, high quality." In network and protocol design, the 302 tradeoffs are often: 304 o The amount of state carried in the system and the speed at which 305 it changes, or simply the state. The amount of state required to 306 operate a system as it scales tends to be nonlinear. Some 307 instances of this are described in [RFC3439] section 2.2.1, the 308 Amplification Principle. 310 o The number of interaction surfaces between the components that 311 make up the complete system, and the depth of those interaction 312 surfaces. Some examples of surfaces are described in 313 [RFC3439]section 2.2.2, the Coupling Principle. Layering is 314 essentially a form of abstraction; all abstractions are subject to 315 the law of leaky abstractions, [LEAKYABS] which states: "all 316 nontrivial absractions leak." 318 o The desired optimization, including efficient use of network 319 resources, optimal support for business objectives, and optimal 320 support for a specific set of applications. 322 These three make up a "triangle problem." For instance, to increase 323 the optimization of traffic flow through a network generally requires 324 adding more state to the control plane, leading to problems in 325 complexity due to amplification. To reduce amplification, the 326 control plane (or perhaps the various functions the control plane 327 serves) can be broken up into subsystems, or modules. Breaking the 328 control plane up into subsystems, however, introduces interaction 329 surfaces between the components, which is another form of complexity. 330 [RFC7980] provides a good overview of network complexity; in 331 particular, section 3 of that document provides some examples of 332 complexity tradeoffs. 334 2.3. Layered Structure 336 The Internet data plane is organized around broad top and bottom 337 layers, and much thinner middle layer. This is illustrated in the 338 figure below. 340 \ / 341 \ HTTP, FTP, SNMP, ETC. / 342 \ / 343 \ TCP, UDP / 344 \ / 345 \ IPv6 / 346 / (IPv4) \ 347 / \ 348 / (MPLS) \ 349 / Ethernet, Wireless \ 350 / Physical Media \ 351 / \ 353 Figure 1 355 This layering emulates or mirrors many naturally occurring systems; 356 it is a common strategy for managing complexity (see Meyer's 357 presentation on complexity). [COMPLEXLAYER] The single protocol in 358 the center, IPv6, serves to separate the complexity of the lower 359 layers from the complexity of the upper layers. This center layer of 360 the Internet ecosystem has traditionally been called the Network 361 Layer, in reference to the Department of Defense (DoD) [DoD] and OSI 362 models. [OSI] The Internet ecosystem includes two different 363 protocols in this central location. 365 o IPv4, an older network protocol that, it is anticipated, will be 366 replaced over time as the Internet ecosystem standardizes on IPv6 368 o IPv6, a newer network protocol that is being adopted 370 MPLS is often used as a "middle" subtransport layer, and at other 371 times as "middle" sub data link layer; hence MPLS is difficult to 372 classify within the strictly hierarchical model depicted here. These 373 protocols are often treated as if they exist in strict hierarchical 374 layers with a well defined and followed Application Programming 375 Interface (API), data models, Remote Procedure Calls (RPCs), sockets, 376 etc. The reality, however, is there are often solid reasons for 377 violating these layers, creating interaction surfaces that are often 378 deeper than intended or understood without some experience. Beyond 379 this, such layering mechanisms act as information abstractions. It 380 is well known that all such abstractions leak (see above on the law 381 of leaky abstractions). Because of these intentional and 382 unintentional leakages of information, the interactions between 383 protocols is often subtle. 385 2.4. Routers 387 A router connects to two or more logical interfaces and at least one 388 physical interface. A router processes packets by: 390 o Receiving a packet through an interface 392 o Stripping the data link, physical header, or tunnel encapsulation 393 off the packet 395 o Examining the packet for errors, and determining if this packet 396 needs to be punted to another process on the router 398 o Looking up the destination in a local forwarding table 400 o Rewriting the data link and/or physical layer header 402 o Transmitting the packet out an interface 404 When consulting the forwarding table, the router searches for a match 405 based on: 407 o The longest prefix containing the destination address (this is the 408 most common matching element) 410 o A label, such as a flow label or MPLS label 412 o The source address or other header fields (not common) 414 The router then examines the information in the matching entry to 415 determine the next hop, or rather the next logically connected device 416 to forward the packet to. The next hop will either be another 417 router, which will presumably carry the packet closer to the final 418 destination, or it will be the destination host itself. The 419 following figure provides a conceptual model of a router; not all 420 routers actually have this set of tables and interactions, and some 421 have many more moving parts. This model is simply used as a common 422 reference to promote understanding. 424 +-------------+ +-------------+ 425 | Candidate | | Startup | 426 | Config |<--+ +-->| Config | 427 +--+----------+ | | +-------+-----+ 428 | | | | 429 v | | v 430 +-----------------+----+-----------------+ 431 | Running Configuration +------>----------+ 432 +---+----------+----------+----------+---+ | 433 | | | | | 434 v | | | | 435 +-------+ | | | | 436 | IS-IS |<-----------------------------------> Adjacent | 437 +---+---+ v | | Routers | 438 | +-------+ | | | 439 | | BGP |<------------------------> Peers | 440 | +---+---+ v | | 441 | | +-------+ | | 442 | | | OSPF |<-------------> Adjacent | 443 | | +---+---+ v Routers | 444 | | | +-------+ | 445 | | | | Other | | 446 | | | +---+---+ | 447 | | | | | 448 +---+----------+----------+----------+---+ | 449 | RIB Manager | | 450 +---+------------------------------------+ | 451 | | 452 +---+------------------------------------+ | 453 | Routing Information Base (RIB) | | 454 +---+------------------------------------+ | 455 | | 456 +---+------------------------------------+ | 457 | Forwarding Information Base (FIB) | | 458 +---+----------+---------------------+---+ | 459 | | | | 460 +---+---+ +---+---+ +---+---+ | 461 | Int 1 | | Int 2 | ... | Int X | <---------------+ 462 +-------+ +-------+ +-------+ 463 ^ | 464 | v 465 Packets In Packets Out 467 Figure 2 469 3. Requirements Related to Device Management and Security 471 Network engineering began in the era of Command Line Interfaces 472 (CLIs), and has generally stayed with these CLIs even as the 473 Graphical User Interface (GUI) has become the standard way of 474 interacting with almost every other computing device. Direct human 475 interaction with routers and middleboxes in large scale and complex 476 environments, however, tends to result in an unacceptably low Mean 477 Time Between Mistakes (MTBM), directly impacting the overall 478 availability of the network. In reaction to this, operators have 479 increased their reliance on automation, specifically targetting 480 machine to machine intefaces, such as Remote Procesdure Calls (RPCs) 481 and Application Programming Interface (API) solutions, to manage and 482 configure routers and middleboxes. This section considers the 483 various components of device management. 485 3.1. Programmable Device Access 487 Configuration primarily relates to the startup, candidate, and 488 running configurations in the router model shown above. In order to 489 deploy networks at scale, operators rely on automated management of 490 router configuration. This effort has traditionally focused on 491 Simple Network Management Protocol (SNMP) Management Information Base 492 (MIBs). In the future, operators expect to move towards open source/ 493 open standards YANG models. 495 Vendors and implementors should implement machine readable interfaces 496 with overlays to support human interaction, rather than human 497 readable interfaces with overlays to support machine to machine 498 interaction. Emphasis should be placed on machine to machine 499 interaction for day to day operations, rather than on human readable 500 interfaces, which are largely used in the process of troubleshooting. 501 Within the realm of machine to machine interfaces, emphasis should be 502 placed on marshaling information in YANG models. 504 To support automated router configuration, IPv6 routers and routers 505 SHOULD support YANG and SNMP configuration, including (but not 506 limited to): 508 o Openconfig models [OPENCONF] related to the protocols configured 509 on the device, interface state, and device state 511 o [RFC7223]: A YANG Data Model for Interface Management 513 o [RFC7224]: IANA Interface Type YANG Module 515 o [RFC7277]: A YANG Data Model for IP Management 516 o [RFC7317]: A YANG Data Model for System Management 518 o Simple Network Management Protocol (SNMP) MIBs as appropriate 520 3.2. Human Readable Device Access 522 To operate a network at scale, operators rely on the ability to 523 access routers and middleboxes to troubleshoot and gather state 524 manually through a number of different interfaces. These interfaces 525 should provide current device configuration, current device state 526 (such as interface state, packets drops, etc.), and current control 527 plane contents (such as the RIB in the figure above). In other 528 words, manual interfaces should provide information about the router 529 (the whole device stack). 531 To support manual state gathering and troubleshooting, IPv6 routers 532 and middleboxes SHOULD support: 534 o TELNET ([RFC0854]): TELNET SHOULD be disabled by default, but 535 should be available for operational purposes as required or as 536 configured by the operator 538 o SSH ([RFC4253]): SSH SHOULD be the default access for IPv6 capable 539 routers 541 o All network devices supporting IPv6 MUST support Ethernet console 542 access 544 3.3. Supporting Zero Touch Provisioning for Connected Devices 546 To operate a network at scale, operators rely on protocols and 547 mechanisms that reduce provisioning time to a minimum. The preferred 548 state is zero touch provisioning; plug a new router in and it just 549 works without any manual configuration. The closer an operator can 550 come to this ideal, the more MTBM and Operational Expenses (OPEX) can 551 be reduced -- an important goals in the real world. IPv6 routers 552 should support several standards, including, but not limited to: 554 o [I-D.ietf-dhc-rfc3315bis]: Dynamic Configuration Protocol for IPv6 555 MUST be supported. SLAAC MUST be able to be disabled by operators 556 who prefer to use some other mechanism for address management and 557 assignment (specifically for customer facing edge ports). 559 o [RFC4862]: IPv6 Stateless Address Autoconfiguration (SLAAC) MUST 560 be supported, and MUST be enabled by default on all router 561 interfaces. 563 o [RFC7217]: Semantically Opaque Interface Identifiers SHOULD be 564 supported. 566 o [RFC7527]: Enhanced Duplicate Address Detection MUST be supported. 568 o [RFC8028]: First-Hop Router Selection by Hosts, specifically 569 section 2.1, which says a router SHOULD be able to send a PIO with 570 both the L and A bits cleared. 572 o [RFC3810]: Routers supporting IPv6 MUST support Multicast Listener 573 Discovery Version 2 575 The provisioning of Domain Name Systems (DNS) system information is a 576 contentious topic, based on provider, operating system, interface, 577 and other requirements. This document therefore addresses the 578 mechanisms that must be included in IPv6 router implementations, but 579 leaves the option of what to configure and deploy to the network 580 operator. Routers supporting IPv6, and intended for user facing 581 connections, MUST support: 583 o [RFC3646]: DNS Configuration options for Dynamic Host 584 Configuration Protocol for IPv6 (DHCPv6). 586 o [RFC8106]: IPv6 Router Advertisement Options for DNS 587 Configuration. This includes the ability to send Router 588 Advertisements (RAs) with DNS information. 590 Whether these are enabled by default, or require extra configuration, 591 is left as an exercise for providers and implementation developers to 592 determine on a case by case basis. 594 3.4. Device Protection against Denial of Service Attacks 596 Denial of Service (DoS) and Distributed Denial of Service (DDoS) 597 attacks are unfortunately common in the Internet globally; these 598 types of attacks cost network operators a great deal in opportunity 599 and operational costs in prevention and responses. To provide for 600 effective counters to DoS and DDoS attacks directly on routers: 602 o Manufacturers and system integrators should test and clearly 603 report the packet/traffic load handling capabilities of devices 604 with and without various encryption methods enabled 606 o Routers should be able to police traffic destined to the control 607 plane based on the rate of traffic received, including the ability 608 ot police individual flows, targeted services, etc., at individual 609 rates as described in [RFC6192] 611 o Ideally, devices should be able to statefully filter traffic 612 destined to the control plane 614 There are other useful techniques for dealing with DDoS attacks at 615 the network level, including: transferring sessions to a new address 616 and abandoning the address under attack, using BGP communities to 617 spread the attack over multiple ingress ports and "consume" it, and 618 requiring mutual authentication before allocating larger resource 619 pools to a connection. These techniques are not "device level," and 620 hence are not considered further here. 622 4. Requirements Related to Telemetry 624 Telemetry relates to information devices push to systems used to 625 monitor and track the state of the network. This applies to 626 individual devices as well as the network as a system. Two major 627 challenges face operators in the area of telemetry: 629 o Information that is laid out primarily for human, rather than 630 machine, consumption. While human consumption of telemetry is 631 important in some situations, this information should be supplied 632 in a form that focuses on machine readability with an overlay or 633 interpretor that allows human consumption. 635 o Software systems that require information to be queried (or polled 636 or even pushed) on a per-item basis. This form of organization 637 can produce a lot of information, and a lot of individual packets, 638 very quickly, overwhelming monitoring systems and consuming a 639 large amount of available network resources. Instead, telemetry 640 should be focused on bulk collection. 642 There are three broad categories of telemetry: device state and 643 traceability, topology state and traceability, and flow traceability. 644 These three roughly correspond to the management plane, the control 645 plane, and the forwarding plane of the network. Each of the sections 646 below considers one of these three telemetry types. 648 4.1. Device State and Traceablity 650 Ideally, the entire network could be monitored using a single 651 modeling language to ease implementation of telemetry systems and 652 increase the pace at which new software can be deployed in production 653 environments. In real deployments, it is often impossible to reach 654 this ideal; however, reducing the languages and methods used, while 655 focusing on machine readibility, can greatly ease the deployment and 656 management of a large scale network. Specifically, IPv6 routers 657 SHOULD support: 659 o [RFC6241]: NETCONF/RESTCONF transporting telemetry formatted 660 according to YANG (see above) 662 o [RFC5424]: Syslog 664 o gRPC based telemetry interfaces [GRPC] 666 o SNMP as appropriate 668 Syslog and SNMP access for telemetry should be considered "legacy," 669 and should not be the focus of new telemetry access development 670 efforts. 672 4.2. Topology State and Traceability 674 IPv6 routers are part of a system of devices that, combined, make up 675 the entire network. Viewing the network as a system is often crucial 676 for operational purposes. For instance, being able to understand 677 changes in the topology and utlization of a network can lead to 678 insights about traffic flow and network growth that lead to a greater 679 understanding of how the network is operating, where problems are 680 developing, and how to improve the network's performance. To support 681 systemic monitoring of the network topology, IPv6 devices SHOULD 682 support at least: 684 o [RFC5424]: North-Bound Distribution of Link-State and Traffic 685 Engineering (TE) Information using BGP 687 o [I-D.ietf-i2rs-yang-l2-network-topology]: An I2RS model for layer 688 2 topologies 690 o [I-D.ietf-i2rs-yang-l3-topology]: An I2RS model for layer 3 691 topologies 693 o [I-D.ietf-i2rs-yang-network-topo]: A Data Model for Network 694 Topologies 696 5. Requirements Related to IPv6 Forwarding and Addressing 698 There are a number of capabilities that a device SHOULD have to be 699 deployed into an IPv6 network, and several forwarding plane 700 considerations operators and vendors need to bear in mind. The 701 sections below explain these considerations. 703 5.1. The IPv6 Address is not a Host Identifier 705 The IPv6 address is commonly treated as a host identifier; it is not. 706 Rather, it is an interface identifier that describes the topological 707 point where a particular host connects to the Internet. 708 Specifically: 710 o The IPv6 address will change when a device changes where it 711 connects to the network. 713 o A single host can have multiple addresses. For instance, a host 714 may have one address per interface, or multiple addresses assigned 715 through different mechanisms, or through multiple connection 716 points. 718 o A single IPv6 address may represent many hosts, as in the case of 719 a group of hosts reachable through multicast address, or a set of 720 services reachable through an anycast address. 722 Because the host address may change at any time, it is generally 723 harmful to embed IPv6 addresses inside upper layer headers to 724 identify a particular host. 726 5.2. Router IPv6 Addresseses 728 Internet Routing Registries may allocate a network operator a wide 729 range of prefix lengths (see [RFC6177] for further information). 730 Within this allocation, network operators will often suballocate 731 address space along nibble boundaries (/48, /52, /56, /60, and /64) 732 for ease of configuration and management. Several common practices 733 are: 735 o Each multiaccess interface is allocated a /64 737 o Point-to-point links are allocated a /64, but SHOULD be addressed 738 with a longer prefix length to prevent certain kinds of denial of 739 service attacks ([RFC3627] originally mandated 64 bit prefix 740 lengths on point-to-point links; [RFC6164] explains possible 741 security issues with assigning a 64 bit prefix length to a point- 742 to-point, and recommends a /127 instead) 744 o Although aggregation may only performed to the nibble boundaries 745 noted above, variances are possible 747 o Loopback addresses are assigned a /128 749 Given these common practices, routers designed to run IPv6 SHOULD 750 support the following addressing conventions: 752 o The default prefix length on any interface other than a loopback 753 SHOULD be a /64 755 o Configuring a prefix length longer than a /64 on any multi-access 756 interface SHOULD require additional configuration steps to prevent 757 manual configuration errors 759 o Routers MUST NOT assume IPv6 prefix lengths only on nibble 760 boundaries 762 o Routers SHOULD support any prefix length shorter or greater than 763 /64 765 o Loopback interfaces SHOULD default to a /128 prefix length unless 766 some additional configuration is undertaken to override this 767 default setting 769 o Routers MUST be able to generate link local addresses on all links 770 and/or interfaces using stateless address autoconfiguration (see 771 [RFC6434]). 773 5.3. The Maximum Transmission Unit 775 The long history of the Maximum Transmission Unit (MTU) in networks 776 is not a happy one. Specific problems with MTU sizing include: 778 o Many different default sizes on different media types, from very 779 small (576 bytes on X.25) to very large (17914 bytes on 16Mbps 780 Token Ring) 782 o Many different ways to calcualte the MTU on any given link; for 783 instance a 9000 byte MTU can be calculated as 8184 bytes on one 784 operating system, 8972 on another, and 9000 on a third 786 o The increasing use of tunnel encapsulations in the network; for 787 instance MPLS over GRE over IP over... 789 o The wide variety of default MTUs across many different end hosts 790 and operating systems 792 o The general ineffectiveness of path MTU discovery to operate 793 correctly in the face of packet filters and rate limiters (see the 794 section on ICMP filtering below) 796 o Lower speed links at the network edge which require a lot of time 797 to serialize a packet with a large MTU 799 o Increased jitter caused by the disparity between large and small 800 packet size across a lower bandwidth links 802 The final point requires some further elucidation. The time required 803 to serialize various packets at various speeds are: 805 o 64 byte packet onto a 10Mb/s link: .5ms 807 o 1500 byte packet onto a 10Mb/s link: 1.2ms 809 o 9000 byte packet onto a 10Mb/s link: 7.2ms 811 o 64 byte packet onto a 100Mb/s link: .05ms 813 o 1500 byte packet onto a 100Mb/s link: .12ms 815 o 9000 byte packet onto a 100Mb/s link: .72ms 817 A 64 byte packet trapped behind a single 1500 byte packet on a 10Mb/s 818 link suffers 1.2ms of serialization delay. Each additional 1500 byte 819 packet added to the queue in front of the 64 byte packet adds and 820 addtional 1.2ms of delay. In contrast, a 64 byte packet trapped 821 behind a single 9000 byte packet on a 10Mb/s link suffers 7.7ms of 822 serialization delay. Each additional 9000 byte packet added to the 823 queue adds an additional 7.2ms of serialization delay. The practical 824 result is that larger MTU sizes on lower speed links can add a 825 significant amount of delay and jitter into a flow. On the other 826 hand, increasing the MTU on higher speed links appears to add 827 megligable additional delay and jitter. 829 The result is that it costs less in terms of overall systemic 830 performance to use higher MTUs on higher speed links than on lower 831 speed links. Based on this, increasing the MTU across any particular 832 link may not increase overall end-to-end performance, but can greatly 833 enhance the performance of local applications (such as a local BGP 834 peering session, or a large/long standing elephant flow used to 835 transfer data across a local fabric), while also providing room for 836 tunnel encapsulations to be added with less impact on lower MTU end 837 systems. 839 The general rule of thumb is to assume the largest size MTU should be 840 used on higher speed transit only links in order to support a wide 841 array of available link sizes, default MTUs, and tunnel 842 encapsulations. Routers designed for a network core, data center 843 core, or use on the global Internet SHOULD support at least 9000 byte 844 MTUs on all interfaces. MTU detection mechanisms, such as IS-IS 845 hello padding, described in [RFC7922], SHOULD be enabled to ensure 846 correct point-to-point MTU configuration. Devices SHOULD also 847 support: 849 o [RFC1981]: Path MTU Discovery for IP version 6 851 o [RFC4821]: Packetization Layer Path MTU Discovery 853 5.4. ICMP Considerations 855 Internet Control Message Protocool (ICMP) is described in [RFC0792] 856 and [RFC4443]. ICMP is often used to perform a traceroute through a 857 network (normally by using a TTL expired ICMP message), for Path MTU 858 discovery, and, in IPv6, for autoconfiguration and neighbor 859 discovery. ICMP is often blocked by middleboxes of various kinds 860 and/or ICMP filters configured on the ingress edge of a provider 861 network, most often to prevent the discovery of reachable hosts and 862 network topology. Routers implementing IPv6: 864 o SHOULD NOT filter ICMP unreachables by default, as this has 865 negative impacts on many aspects of IPv6 operation, particularly 866 path MTU 868 o SHOULD filter ICMP echo and echo response by default, to prevent 869 the discovery of reachable hosts and topology. 871 o SHOULD rate limit the generation of ICMP messages relative to the 872 ability of the device to generate packets and to block the use of 873 ICMP packets being used as part of a distributed denial of service 874 attack 876 o SHOULD implement the filtering suggestions in 877 [I-D.gont-opsec-icmp-ingress-filtering] 879 There are implications for path MTU discovery and other useful 880 mechanisms in filtering and rate limiting ICMP. The tradeoff here is 881 between allowing unlimited ICMP, which would allow path MTU detection 882 to work, or limiting ICMP in a way that prevents negative side 883 effects for individual devices, and hence the operational 884 capabilities of the network as a whole. Operators rightly limit ICMP 885 to reduce the attack surface against their network, as well as the 886 opportinity for "perfect storm" events that inadvertently reduce the 887 capability of routers and middleboxes. Hence ICMP can be treated as 888 "quasi-reliable" in many situations; existence of an ICMP message can 889 prove, for instance, that a particular host is unreachable. The non- 890 existence of an ICMP message, however, does not prove a particular 891 host exists or does not. 893 5.5. Machine Access to the Forwarding Table 895 In order to support treating the "network as a whole" as a single 896 programmable system, it is important for each router have the ability 897 to directly program forwarding information. This programmatic 898 interface allows controllers, which are programmed to support 899 specific business logic and applications, to modify and filter 900 traffic flows without interfering with the distributed control plane. 901 While there are several programmatic interfaces available, this 902 document suggests that the I2RS interface to the RIB be supported in 903 all IPv6 routers. Specifically, these drafts should be supported to 904 enable network programmability: 906 o [I-D.ietf-i2rs-fb-rib-data-model]: Filter-Based RIB Data Model 908 o [I-D.ietf-i2rs-fb-rib-info-model]: Filter-Based RIB Information 909 Model 911 o [I-D.ietf-i2rs-rib-data-model]: A YANG Data Model for Routing 912 Information Base (RIB) 914 o [RFC7922]: I2RS Traceability 916 5.6. Processing IPv6 Extension Headers 918 (To be added) 920 5.7. IPv6 Only Operation 922 While the transition to IPv6 only networks may take years (or perhaps 923 decades), a number of operators are moving to deploy IPv6 on internal 924 networks supporting transport and data center fabric applications 925 more quickly. Routers and middleboxes that support IPv6 SHOULD 926 support IPv6 only operation, including: 928 o Link Local addressing MUST be configurable and useable as the 929 primary address on all interfaces on a device. 931 o IPv4 and/or MPLS SHOULD NOT be required for proper device 932 operation. For instance, an IPv4 address should not be required 933 to determine the router ID for any protocol. See [RFC6540] 934 section 2. 936 o Any control plane protocol implementations MUST support the 937 recommendations in [RFC7404] for operation using link local 938 addresses only. 940 5.8. Prefix Length Handling in IPv6 PAcket Forwarding 942 Routers MUST support IPv6 destination lookups in the forwarding 943 process on a single bit prefix length increments, in accordance with 944 [RFC7608]. 946 6. Security Considerations 948 This document addresses several ways in which devices designed to 949 support IPv6 forwarding. Some of the recommendations here are 950 designed to increase device security; for instance, see the section 951 on device access. Others may intersect with security, but are not 952 specifically targeted at security, such as running IPv6 link local 953 only on links. These are not discussed further here, as they improve 954 the security stance of the network. Other areas discussed in this 955 draft are more nuanced. This section gathers the intersection 956 between operational concerns and security concerns into one place. 958 ICMP security is already considered in the section on ICMP; it will 959 not be considered further here. Link local only addressing wil 960 increase security by removing transit only links within the network 961 as a reachable destination. 963 6.1. Robustness and Security 965 Robustness, particularly in the area of error handling, largely 966 improves security if designed and implemented correctly. Many 967 attacks take advantage of mistakes in implementations and variations 968 in protocols. In particular, any feature that is unevenly 969 implemented among a number of implementations often offers an attack 970 surface. Hence, reducing protocol complexity helps reduce the 971 breadth of attack surfaces. 973 Another point to consider at the intersection of robustness and 974 security is the issue of monocultures. Monocultures are in and of 975 themselves a potential attack surface, in that finding a single 976 failure mode can be exploited to take an entire network (or operator) 977 down. On the other hand, reducing the number of implementations for 978 any particular protocol will decrease the set of "random" features 979 deployed in the network. These two goals will often be opposed to 980 one another. Network designers and operators need to consider these 981 two sides of this tradeoff, and make an intelligent decision about 982 how much diversity to implement versus how to control the attack 983 surface represented by deploying a wide array of implementations. 985 6.2. Programmable Device Access and Security 987 Programmable interfaces, including programmable configuration, 988 telemetry, and machine interface to the routing table, introduce a 989 large attack surface; operators should be careful to ensure this 990 attack surface is properly secured. Specifically: 992 o Prevent external access to any administrative access points used 993 for device programmability 995 o Use AAA systems to ensure only valid devices and/or users access 996 devices 998 o Rate limit the change rate and protect management interfaces from 999 DoS and DDoS attacks 1001 Such interfaces should be treated no differently than SSH, SFTP, and 1002 other interfaces available to manage routers and middleboxes. 1004 6.3. Zero Touch Provisioning and Security 1006 Zero touch provisioning opens a new attack surface; insider attackers 1007 can simply install a new device, and assume it will be autoconfigured 1008 into the network. A "simple" solution would be to install door 1009 locks, but this will likely not be enough; defenses need to be 1010 layered to be effective. It is recommended that devices installed in 1011 the network need to contain a hardware or software identification 1012 system that allows the operator to identify devices that are 1013 installed in the network. 1015 7. Conclusion 1017 The deployment of IPv6 throughout the Internet marks a point in time 1018 where it is good to review the overall Internet architecture, and 1019 assess the impact on operations of these changes. This document 1020 provides an overview of a lot of these changes and lessons learned, 1021 as well as providing pointers to many of the relevant documents to 1022 understand each topic more deeply. 1024 8. References 1026 8.1. Normative References 1028 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1029 Requirement Levels", BCP 14, RFC 2119, 1030 DOI 10.17487/RFC2119, March 1997, 1031 . 1033 8.2. Informative References 1035 [COMPLEXHARD] 1036 Alderson, D. and J. Doyle, "Contrasting Views of 1037 Complexity and Their Implications For Network-Centric 1038 Infrastructures", 2010, 1039 . 1042 [COMPLEXLAYER] 1043 Meyer, D., "Macro Trends, Architecture, and the Hidden 1044 Nature of Complexity", 2010, 1045 . 1048 [DoD] Wikipedia, "The Internet Protocol Suite", 2016, 1049 . 1051 [GRPC] gRPC, "gRPC", 2016, . 1053 [I-D.gont-opsec-icmp-ingress-filtering] 1054 Gont, F., Hunter, R., Massar, J., and S. LIU, "Defeating 1055 Attacks which employ Forged ICMP/ICMPv6 Error Messages", 1056 draft-gont-opsec-icmp-ingress-filtering-02 (work in 1057 progress), March 2016. 1059 [I-D.iab-protocol-transitions] 1060 Thaler, D., "Planning for Protocol Adoption and Subsequent 1061 Transitions", draft-iab-protocol-transitions-08 (work in 1062 progress), March 2017. 1064 [I-D.ietf-dhc-rfc3315bis] 1065 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1066 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1067 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 1068 bis", draft-ietf-dhc-rfc3315bis-07 (work in progress), 1069 March 2017. 1071 [I-D.ietf-i2rs-fb-rib-data-model] 1072 Hares, S., Kini, S., Dunbar, L., Krishnan, R., Bogdanovic, 1073 D., and R. White, "Filter-Based RIB Data Model", draft- 1074 ietf-i2rs-fb-rib-data-model-01 (work in progress), March 1075 2017. 1077 [I-D.ietf-i2rs-fb-rib-info-model] 1078 Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, 1079 R., Bogdanovic, D., and R. White, "Filter-Based RIB 1080 Information Model", draft-ietf-i2rs-fb-rib-info-model-00 1081 (work in progress), June 2016. 1083 [I-D.ietf-i2rs-rib-data-model] 1084 Wang, L., Ananthakrishnan, H., Chen, M., 1085 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 1086 YANG Data Model for Routing Information Base (RIB)", 1087 draft-ietf-i2rs-rib-data-model-07 (work in progress), 1088 January 2017. 1090 [I-D.ietf-i2rs-yang-l2-network-topology] 1091 Dong, J. and X. Wei, "A YANG Data Model for Layer-2 1092 Network Topologies", draft-ietf-i2rs-yang-l2-network- 1093 topology-03 (work in progress), July 2016. 1095 [I-D.ietf-i2rs-yang-l3-topology] 1096 Clemm, A., Medved, J., Varga, R., Liu, X., 1097 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1098 for Layer 3 Topologies", draft-ietf-i2rs-yang- 1099 l3-topology-08 (work in progress), January 2017. 1101 [I-D.ietf-i2rs-yang-network-topo] 1102 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1103 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1104 Topologies", draft-ietf-i2rs-yang-network-topo-12 (work in 1105 progress), March 2017. 1107 [I-D.ietf-netconf-restconf] 1108 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1109 Protocol", draft-ietf-netconf-restconf-18 (work in 1110 progress), October 2016. 1112 [LEAKYABS] 1113 Spolsky, J., "The Law of Leaky Abstractions", 2002, 1114 . 1117 [OPENCONF] 1118 OpenConfig, "Openconfig release YANG models", 2016, 1119 . 1122 [OSI] Wikipedia, "OSI Model", 2016, 1123 . 1125 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1126 RFC 792, DOI 10.17487/RFC0792, September 1981, 1127 . 1129 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 1130 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1131 1983, . 1133 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 1134 RFC 1812, DOI 10.17487/RFC1812, June 1995, 1135 . 1137 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1138 and E. Lear, "Address Allocation for Private Internets", 1139 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1140 . 1142 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1143 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1144 1996, . 1146 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1147 DOI 10.17487/RFC2629, June 1999, 1148 . 1150 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 1151 Guidelines and Philosophy", RFC 3439, 1152 DOI 10.17487/RFC3439, December 2002, 1153 . 1155 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1156 Text on Security Considerations", BCP 72, RFC 3552, 1157 DOI 10.17487/RFC3552, July 2003, 1158 . 1160 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 1161 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 1162 September 2003, . 1164 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1165 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1166 DOI 10.17487/RFC3646, December 2003, 1167 . 1169 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1170 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1171 DOI 10.17487/RFC3810, June 2004, 1172 . 1174 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1175 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1176 January 2006, . 1178 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1179 Control Message Protocol (ICMPv6) for the Internet 1180 Protocol Version 6 (IPv6) Specification", RFC 4443, 1181 DOI 10.17487/RFC4443, March 2006, 1182 . 1184 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1185 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1186 . 1188 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1189 Address Autoconfiguration", RFC 4862, 1190 DOI 10.17487/RFC4862, September 2007, 1191 . 1193 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 1194 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1195 . 1197 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 1198 DOI 10.17487/RFC5424, March 2009, 1199 . 1201 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1202 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1203 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 1204 . 1206 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1207 Assignment to End Sites", BCP 157, RFC 6177, 1208 DOI 10.17487/RFC6177, March 2011, 1209 . 1211 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1212 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1213 March 2011, . 1215 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1216 and A. Bierman, Ed., "Network Configuration Protocol 1217 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1218 . 1220 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1221 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 1222 2011, . 1224 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1225 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1226 RFC 6540, DOI 10.17487/RFC6540, April 2012, 1227 . 1229 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1230 Interface Identifiers with IPv6 Stateless Address 1231 Autoconfiguration (SLAAC)", RFC 7217, 1232 DOI 10.17487/RFC7217, April 2014, 1233 . 1235 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1236 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1237 . 1239 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1240 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1241 . 1243 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1244 RFC 7277, DOI 10.17487/RFC7277, June 2014, 1245 . 1247 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1248 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1249 2014, . 1251 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 1252 Addressing inside an IPv6 Network", RFC 7404, 1253 DOI 10.17487/RFC7404, November 2014, 1254 . 1256 [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., 1257 and W. George, "Enhanced Duplicate Address Detection", 1258 RFC 7527, DOI 10.17487/RFC7527, April 2015, 1259 . 1261 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 1262 Length Recommendation for Forwarding", BCP 198, RFC 7608, 1263 DOI 10.17487/RFC7608, July 2015, 1264 . 1266 [RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the 1267 IAB Workshop on Stack Evolution in a Middlebox Internet 1268 (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, 1269 . 1271 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1272 the Routing System (I2RS) Traceability: Framework and 1273 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 1274 2016, . 1276 [RFC7980] Behringer, M., Retana, A., White, R., and G. Huston, "A 1277 Framework for Defining Network Complexity", RFC 7980, 1278 DOI 10.17487/RFC7980, October 2016, 1279 . 1281 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 1282 Hosts in a Multi-Prefix Network", RFC 8028, 1283 DOI 10.17487/RFC8028, November 2016, 1284 . 1286 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1287 "IPv6 Router Advertisement Options for DNS Configuration", 1288 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1289 . 1291 Authors' Addresses 1293 Zaid Ali Kahn (editor) 1294 LinkedIn 1295 xxx 1296 xxx, CA xxx 1297 USA 1299 Email: zaid@linkedin.com 1301 John Brzozowski (editor) 1302 Comcast 1303 xxx 1304 xxx, xxx xxx 1305 USA 1307 Email: John_Brzozowski@comcast.com 1308 Russ White (editor) 1309 LinkedIn 1310 Oak Island, NC 28465 1311 USA 1313 Email: russ@riw.us