idnits 2.17.00 (12 Aug 2021) /tmp/idnits9334/draft-ietf-v6ops-ipv6rtr-reqs-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 26, 2018) is 1449 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7991' is defined on line 1441, but no explicit reference was found in the text == Outdated reference: draft-ietf-dhc-rfc3315bis has been published as RFC 8415 == Outdated reference: draft-ietf-i2rs-rib-data-model has been published as RFC 8431 == Outdated reference: draft-ietf-i2rs-yang-l2-network-topology has been published as RFC 8944 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-02 == Outdated reference: draft-ietf-netconf-yang-push has been published as RFC 8641 -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 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 27, 2018 Comcast 6 R. White, Ed. 7 LinkedIn 8 May 26, 2018 10 Requirements for IPv6 Routers 11 draft-ietf-v6ops-ipv6rtr-reqs-04 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 interconnected 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 interconnected environment can have a major 21 impact 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 necessary background to 32 guide equipment manufacturers, protocol implementors, 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 https://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 27, 2018. 51 Copyright Notice 53 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . 3 70 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 71 1.3. Use and Applicability . . . . . . . . . . . . . . . . . . 4 72 2. Review of the Internet Architecture . . . . . . . . . . . . . 5 73 2.1. Robustness Principle . . . . . . . . . . . . . . . . . . 5 74 2.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 7 75 2.2.1. Elegance . . . . . . . . . . . . . . . . . . . . . . 7 76 2.2.2. Trade-offs . . . . . . . . . . . . . . . . . . . . . 8 77 2.3. Layered Structure . . . . . . . . . . . . . . . . . . . . 9 78 2.4. Routers . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3. Requirements Related to Device Management and Security . . . 12 80 3.1. Programmable Device Access . . . . . . . . . . . . . . . 12 81 3.2. Human Readable Device Access . . . . . . . . . . . . . . 13 82 3.3. Supporting Zero Touch Provisioning for Connected Devices 13 83 3.4. Device Protection against Denial of Service Attacks . . . 15 84 4. Requirements Related to Telemetry . . . . . . . . . . . . . . 15 85 4.1. Device State and Traceablity . . . . . . . . . . . . . . 16 86 4.2. Topology State and Traceability . . . . . . . . . . . . . 16 87 4.3. Flow State and Traceability . . . . . . . . . . . . . . . 17 88 5. Requirements Related to IPv6 Forwarding and Addressing . . . 17 89 5.1. The IPv6 Address is not a Host Identifier . . . . . . . . 17 90 5.2. Router IPv6 Addresses . . . . . . . . . . . . . . . . . . 18 91 5.3. The Maximum Transmission Unit . . . . . . . . . . . . . . 19 92 5.4. ICMP Considerations . . . . . . . . . . . . . . . . . . . 20 93 5.5. Machine Access to the Forwarding Table . . . . . . . . . 21 94 5.6. Processing IPv6 Extension Headers . . . . . . . . . . . . 22 95 5.7. IPv6 Operation by Default . . . . . . . . . . . . . . . . 22 96 5.8. IPv6 Only Operation . . . . . . . . . . . . . . . . . . . 22 97 5.9. Prefix Length Handling in IPv6 Packet Forwarding . . . . 23 98 5.10. IPv6 Mobility Support . . . . . . . . . . . . . . . . . . 23 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 100 6.1. Robustness and Security . . . . . . . . . . . . . . . . . 23 101 6.2. Programmable Device Access and Security . . . . . . . . . 24 102 6.3. Zero Touch Provisioning and Security . . . . . . . . . . 24 103 6.4. Defaulting to IPv6 Forwarding and Security . . . . . . . 24 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 105 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 25 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 107 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 108 9.2. Informative References . . . . . . . . . . . . . . . . . 25 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 111 1. Introduction 113 This memo defines and discusses requirements for devices that perform 114 forwarding for Internet Protocol version 6 (IPv6). The "use and 115 applicability" section below contains more information on the 116 specific target of this draft, and the envisioned use of the draft. 118 Readers should recognize that while this memo applies to IPv6, 119 routers and middleboxes IPv6 packets will often also process IPv4 120 packets, forward based on MPLS labels, and potentially process many 121 other protocols. This memo will only discuss IPv4, MPLS, and other 122 protocols as they impact the behavior of an IPv6 forwarding device; 123 no attempt is made to specify requirements for protocols other than 124 IPv6. The reader should, therefore, not count on this document as a 125 "sole source of truth," but rather use this document as a guide. 127 For IPv4 router requirements, readers are referred to [RFC1812]. For 128 simplicity, the term "devices" is used interchangeably with the 129 phrase "routers and middleboxes" and the term "routers" throughout 130 this document. These three terms represent stylistic differences, 131 rather than substantive differences. 133 This document is broken into the following sections: a review of 134 Internet architecture and principles, requirements relating to device 135 management, requirements related to telemetry, requirements related 136 to IPv6 forwarding and addressing, and future considerations. 137 Following these sections, a short conclusion is provided for review. 139 1.1. Contributors 141 Shawn Zandi, Pete Lumbis, Fred Baker, James Woodyatt, Erik Muller, 142 Lee Howard, and Joe Clarke contributed significant text and ideas to 143 this draft. 145 1.2. Acknowledgments 147 The editors and contributors would like to thank Ron Bonica, Lorenzo 148 Coitti, Brian E. Carpenter, Tim Chown, Peter Lothberg, and Mikael 149 Abrahamsson for their comments, edits, and ideas on the text of this 150 draft. 152 1.3. Use and Applicability 154 The conceived use of this draft is as a reference point. The first 155 part of the draft is designed to help IPv6 implementors and network 156 operators to understand Internet and Internetworking technologies, so 157 they can better understand the context of IPv6. The second part of 158 this draft outlines a common set of requirements for devices which 159 are designed to forward IPv6 traffic. This can include (but is not 160 limited to) the devices described below. 162 o Devices which are primarily designed to forward traffic between 163 more than two interfaces. These are normally referred to by the 164 Internet community as routers or, in some cases, intermediate 165 systems. 167 o Devices which are designed to modify packets rather than "just" 168 forwarding them. These are often referred to by the Internet 169 community as middleboxes. See [RFC7663] for a fuller definition 170 of middleboxes. 172 This draft is not designed to apply to consumer devices, such as 173 smart devices (refrigerators, light bulbs, garage door openers, 174 etc.), Internet of Things (IoT) devices, cell phones primarily used 175 as an end user device (such as checking email, social media, games, 176 and use as a voice device), and other devices of this class. It is 177 up to each provider or equipment purchaser to determine how best to 178 apply this document to their environment. 180 The intended use of this document is for operators to be able to 181 point to a common set of functionality which should be available 182 across all IPv6 implementations. Several members of the community 183 have argued there is no common set of IPv6 features; rather each 184 deployment of IPv6 calls for different feature sets. However, the 185 authors of this draft believe outlining a common set of features 186 expected of every IPv6 forwarding device is useful. Specifically: 188 o If every IPv6 deployment situation is unique, and requires a 189 different set of features, there will not be a solid definition of 190 what an IPv6 forwarding device is, or performs. This fragments 191 the concept of IPv6 forwarding devices in an unhelpful way, 192 especially as IPv6 deployment is already seen as difficult. 194 o It encourages developers and vendors to code a multitude of 195 different IPv6 stacks, one for each possible set of features. 196 This fragments the experience with these stacks, potentially 197 preventing the development of a well designed, fully featured 198 stacks the entire community can rely on. 200 Because this document is designed to be a reference point rather than 201 a best common practice or a standard, this document does not use 202 [RFC2119] upper case "must" and "should" throughout. Rather, it uses 203 lower case "must" and "should" throughout, anticipating operators 204 will find such guidance clear and useful. 206 2. Review of the Internet Architecture 208 The Internet relies on a number of basic concepts and considerations. 209 These concepts are not explicitly called out in any specification, 210 nor do they necessarily impact protocol design or packet forwarding 211 directly. This section provides an overview of these concepts and 212 considerations to help the reader understand the larger context of 213 this document. 215 2.1. Robustness Principle 217 Every point where multiple protocols interact, is an interaction 218 surface that can threaten the robustness of the overall system. 219 While it may seem the global Internet has achieved a level of 220 stability that makes it immune to such considerations, the reality is 221 every network is a complex system, and is therefore subject to 222 massive non repeatable unanticipated failures. Postel's Robustness 223 Principle countered this problem with a simple statement, explicated 224 in [RFC1122]: "Be conservative in what you do, and liberal in what 225 you accept from others." 227 However, since this time, it has been noted that following this law 228 allows errors in protocols to accumulate over time, with overall 229 negative effects on the system as a whole. [RFC1918] describes 230 several points in conjunction with this principle that bear updating 231 based on further experience with large-scale protocol and network 232 deployments within the Internet community, including: 234 o Applications should deal with error states gracefully; an 235 application should not degrade in a way that will cause the 236 failure of adjacent systems when possible. For instance, when a 237 routing protocol implementation fails, it should not do so in a 238 way that will cause the spreading of or continued existence of 239 false reachability information, nor should it fail in a way that 240 overloads adjacent routers or interacting protocols and causing a 241 cascading failure. 243 o It is best to assume the network is filled with poor 244 implementations and malevolent actors, both of which will find 245 every possible failure mode over time. 247 o It is best to assume every technology will be used to the limits 248 of its technical capabilities, rather than assuming a particular 249 protocol's scope of use will align (in any way) with the intent of 250 the original designer(s). [RFC5218] defines a wildly successful 251 protocol as one that "far exceeds its original goals, in terms of 252 purpose (being used in scenarios far beyond the initial design), 253 in terms of scale (being deployed on a scale much greater than 254 originally envisaged), or both." Successful implementations 255 attract more functionality, much like a few nodes in a scale free 256 graph eventually become connectivity hubs. 258 o Protocols and implementations change over time. A corollary of 259 the assumption that protocols will be used until they reach their 260 technical limits is that protocols will change over time as they 261 gain new functionality. [RFC5218] points out several problems 262 with "wild success" in a protocol: undesirable side effects, 263 performance problems, and becoming a high value attack target. 264 Protocol and implementation design should take into account use 265 cases that have not yet been thought of by building flexibility 266 into protocols. Protocols should also remained focused on a 267 narrow range of use cases; it is often wise to invent a new 268 protocol than to extend a single protocol into a broad set of use 269 cases. 271 o Protocols are sometimes replaced or updated to new versions in 272 order to add new capabilities or features. Updating a protocol 273 requires great care in providing for a transition mechanism 274 between older and newer versions. [RFC8170] provides sound advice 275 on protocol transition planning and mechanisms. 277 o Obscure, but legal, protocol features are often ignored or left 278 unimplemented. Protocols must handle receiving unexpected 279 information gracefully so they do not fail because of incomplete 280 or partial implementations. Protocols should avoid specifying 281 contradictory states, or features that will cause interoperability 282 issues if multiple implementations choose to implement different 283 feature sets. 285 o Monocultures are almost always bad. While multiple 286 implementations can represent an interaction surface which 287 increases complexity, particularly if a broad set of protocol 288 capabilities and/or implementation features are used, using the 289 same implementation at every point in a deployment results in a 290 mono-culture. In a monoculture, a single event can trigger a 291 defect in every router, causing a network failure. Mono-cultures 292 must be carefully balanced against interaction surfaces; often 293 this is best accomplished by using multiple implementations and 294 minimal, widely implemented, and well understood protocol 295 features. 297 A summary of the points above might be this: It is important to work 298 within the bounds of what is actually implemented in any given 299 protocol, and to leave corner cases for another day. It is often 300 easy to assume "virtual oceans" are easier to boil than physical 301 ones, or for an ocean to appear much smaller because it is being 302 implemented in software. This is often deceptive. It is never 303 helpful to boil the ocean whether in a design, an implementation, or 304 a protocol. 306 2.2. Complexity 308 Complexity, as articulated by Mike O'Dell (see [RFC3439]), is "the 309 primary mechanism which impedes efficient scaling, and as a result is 310 the primary driver of increases in both capital expenditures (CAPEX) 311 and operational expenditures (OPEX)." At the same time, complexity 312 cannot be "solved," but rather must be "managed." The simplest and 313 most obvious solution to any problem is often easy to design, deploy, 314 and manage. It's also often wrong and/or broken. As much as 315 developers, designers, and operators might like to make things as 316 simple as possible, hard problems require complex solutions. See 317 Alderson and Doyle [COMPLEXHARD] for a discussion of the relationship 318 between hard problems and complex solutions. 320 The following sections contain observations which apply to the 321 management of complexity in both protocol and network design. 323 2.2.1. Elegance 325 Elegance should be the goal of protocol and network design. Rather 326 than seeking out simple solutions because they are simple, seek out 327 solutions that will solve the problem in the simplest way possible 328 (and no simpler). Often this will require: 330 o Ensuring the goal is actually the goal. Many times the goal is 331 taken from the operational realm into the protocol design realm 332 before enough thought has been applied to ensure the correct 333 problem is being addressed. 335 o Seeing the problem from different angles, trying to break the 336 problem up in multiple ways; and trying, abandoning, and 337 rebuilding ideas and implementations until a better way is found. 339 o Sometimes the complexity of the solution will overwhelm the use 340 case; sometimes it is better to leave the apparent problem 341 unsolved, or allow the community time and space to find a simpler 342 solution. 344 2.2.2. Trade-offs 346 There are always trade-offs. For any protocol, network, or 347 operational design decision, there will always be a trade-off between 348 at least two competing goals. If some problem appears to have a 349 single solution without trade-offs, this doesn't mean the trade-offs 350 don't exist. Rather, it means the trade-offs haven't been discovered 351 yet. In the area of protocol and network design, these trade-offs 352 often take the form of common "choose two of three" situations, such 353 as "quick, cheap, high quality." In network and protocol design, the 354 trade-offs are often: 356 o The amount of state carried in the system and the speed at which 357 it changes, or simply the state. The amount of state required to 358 operate a system as it scales tends to be nonlinear. Some 359 instances of this are described in [RFC3439] section 2.2.1, the 360 Amplification Principle. 362 o The number of interaction surfaces between the components that 363 make up the complete system, and the depth of those interaction 364 surfaces. Some examples of surfaces are described in 365 [RFC3439]section 2.2.2, the Coupling Principle. Layering is 366 essentially a form of abstraction; all abstractions are subject to 367 the law of leaky abstractions, [LEAKYABS] which states: "all 368 nontrivial abstractions leak." 370 o The desired optimization, including efficient use of network 371 resources, optimal support for business objectives, and optimal 372 support for a specific set of applications. 374 These three make up a "triangle problem." For instance, to increase 375 the optimization of traffic flow through a network generally requires 376 adding more state to the control plane, leading to problems in 377 complexity due to amplification. To reduce amplification, the 378 control plane (or perhaps the various functions the control plane 379 serves) can be broken up into subsystems, or modules. Breaking the 380 control plane up into subsystems, however, introduces interaction 381 surfaces between the components, which is another form of complexity. 382 [RFC7980] provides a good overview of network complexity; in 383 particular, section 3 of that document provides some examples of 384 complexity trade-offs. 386 2.3. Layered Structure 388 The Internet data plane is organized around broad top and bottom 389 layers, and much thinner middle layer. This is illustrated in the 390 figure below. 392 \ / 393 \ HTTP, FTP, SNMP, ETC. / 394 \ / 395 \ TCP, UDP / 396 \ / 397 \ IPv6 / 398 / (IPv4) \ 399 / \ 400 / (MPLS) \ 401 / Ethernet, Wireless \ 402 / Physical Media \ 403 / \ 405 Figure 1 407 This layering emulates or mirrors many naturally occurring systems; 408 it is a common strategy for managing complexity (see Meyer's 409 presentation on complexity). [COMPLEXLAYER] The single protocol in 410 the center, IPv6, serves to separate the complexity of the lower 411 layers from the complexity of the upper layers. This center layer of 412 the Internet ecosystem has traditionally been called the Network 413 Layer, in reference to the Department of Defense (DoD) [DoD] and OSI 414 models. [OSI] The Internet ecosystem includes two different 415 protocols in this central location. 417 o IPv4, an older network protocol that, it is anticipated, will be 418 replaced over time as the Internet ecosystem standardizes on IPv6 420 o IPv6, a newer network protocol that is being adopted 422 MPLS is often used as a "middle" sub-transport layer, and at other 423 times as "middle" sub data link layer; hence MPLS is difficult to 424 classify within the strictly hierarchical model depicted here. These 425 protocols are often treated as if they exist in strict hierarchical 426 layers with a well defined and followed Application Programming 427 Interface (API), data models, Remote Procedure Calls (RPCs), sockets, 428 etc. The reality, however, is there are often solid reasons for 429 violating these layers, creating interaction surfaces that are often 430 deeper than intended or understood without some experience. Beyond 431 this, such layering mechanisms act as information abstractions. It 432 is well known that all such abstractions leak (see above on the law 433 of leaky abstractions). Because of these intentional and 434 unintentional leakages of information, the interactions between 435 protocols is often subtle. 437 2.4. Routers 439 A router connects to two or more logical interfaces and at least one 440 physical interface. A router processes packets by: 442 o Receiving a packet through an interface 444 o Stripping the data link, physical header, or tunnel encapsulation 445 off the packet 447 o Examining the packet for errors, and determining if this packet 448 needs to be punted to another process on the router 450 o Looking up the destination in a local forwarding table 452 o Rewriting the data link and/or physical layer header 454 o Transmitting the packet out an interface 456 When consulting the forwarding table, the router searches for a match 457 based on: 459 o The longest prefix containing the destination address (this is the 460 most common matching element) 462 o A label, such as a flow label or MPLS label 464 o The source address or other header fields (not common) 466 The router then examines the information in the matching entry to 467 determine the next hop, or rather the next logically connected device 468 to forward the packet to. The next hop will either be another 469 router, which will presumably carry the packet closer to the final 470 destination, or it will be the destination host itself. The 471 following figure provides a conceptual model of a router; not all 472 routers actually have this set of tables and interactions, and some 473 have many more moving parts. This model is simply used as a common 474 reference to promote understanding. 476 +-------------+ +-------------+ 477 | Candidate | | Startup | 478 | Config |<--+ +-->| Config | 479 +--+----------+ | | +-------+-----+ 480 | | | | 481 v | | v 483 +-----------------+----+-----------------+ 484 | Running Configuration | 485 +---+------------------------------------+ 486 | 487 | // configuration transformations 488 | 489 +---+------------------------------------+ 490 | Intended Configuration | 491 +---+------------------------------------+ 492 | 493 | // changes applied subject to local factors 494 | 495 +---+------------------------------------+ 496 | Operational Configuration +------>----------+ 497 +---+----------+----------+----------+---+ | 498 | | | | | 499 v | | | | 500 +-------+ | | | | 501 | IS-IS |<-----------------------------------> Adjacent | 502 +---+---+ v | | Routers | 503 | +-------+ | | | 504 | | BGP |<------------------------> Peers | 505 | +---+---+ v | | 506 | | +-------+ | | 507 | | | OSPF |<-------------> Adjacent | 508 | | +---+---+ v Routers | 509 | | | +-------+ | 510 | | | | Other | | 511 | | | +---+---+ | 512 | | | | | 513 +---+----------+----------+----------+---+ | 514 | RIB Manager | | 515 +---+------------------------------------+ | 516 | | 517 +---+------------------------------------+ | 518 | Routing Information Base (RIB) | | 519 +---+------------------------------------+ | 520 | | 521 +---+------------------------------------+ | 522 | Forwarding Information Base (FIB) | | 523 +---+----------+---------------------+---+ | 524 | | | | 525 +---+---+ +---+---+ +---+---+ | 526 | Int 1 | | Int 2 | ... | Int X | <---------------+ 527 +-------+ +-------+ +-------+ 528 ^ | 529 | v 530 Packets In Packets Out 531 Figure 2 533 The configuration datastores in this figure follow [RFC8342]. 535 3. Requirements Related to Device Management and Security 537 Network engineering began in the era of Command Line Interfaces 538 (CLIs), and has generally stayed with these CLIs even as the 539 Graphical User Interface (GUI) has become the standard way of 540 interacting with almost every other computing device. Direct human 541 interaction with routers and middleboxes in large-scale and complex 542 environments, however, tends to result in an unacceptably low Mean 543 Time Between Mistakes (MTBM), directly impacting the overall 544 availability of the network. In reaction to this, operators have 545 increased their reliance on automation, specifically targeting 546 machine to machine interfaces, such as Remote Procedure Calls (RPCs) 547 and Application Programming Interface (API) solutions, to manage and 548 configure routers and middleboxes. This section considers the 549 various components of device management. 551 Across all interface types, devices should provide and use complete, 552 idempotent, stateless configurations. Further, default settings 553 should be accessible in some way, even if they are hidden by default 554 for configuration readability. 556 3.1. Programmable Device Access 558 Configuration primarily relates to the startup, candidate, running, 559 intended, and operational configurations in the router model shown 560 above. In order to deploy networks at scale, operators rely on 561 automated management of router configuration. This effort has 562 traditionally focused on screen scraping and other proprietary 563 methods of "reading" and "writing" configuration information through 564 a CLI. In the future, operators expect to move towards open source/ 565 open standards YANG models, regardless of how these are encoded and/ 566 or carried (or marshaled). 568 Vendors and implementors should implement machine readable interfaces 569 with overlays to support human interaction, rather than human 570 readable interfaces with overlays to support machine to machine 571 interaction. Emphasis should be placed on machine to machine 572 interaction for day to day operations, rather than on human readable 573 interfaces, which are largely used in the process of troubleshooting. 574 Within the realm of machine to machine interfaces, emphasis should be 575 placed on marshaling information in YANG models. 577 To support automated router configuration, IPv6 routers and routers 578 should support YANG configuration, including (but not limited to): 580 o Openconfig models [OPENCONF] related to the protocols configured 581 on the device, interface state, and device state 583 o [RFC8343]: A YANG Data Model for Interface Management 585 o [RFC7224]: IANA Interface Type YANG Module 587 o [RFC8344]: A YANG Data Model for IP Management 589 o [RFC7317]: A YANG Data Model for System Management 591 o [RFC8349]: A YANG Data Model for Routing Management (NMDA Version) 593 3.2. Human Readable Device Access 595 To operate a network at scale, operators rely on the ability to 596 access routers and middleboxes to troubleshoot and gather state 597 manually through a number of different interfaces. These interfaces 598 should provide current device configuration, current device state 599 (such as interface state, packets drops, etc.), and current control 600 plane contents (such as the RIB in the figure above). In other 601 words, manual interfaces should provide information about the router 602 (the whole device stack). 604 To support manual state gathering and troubleshooting, IPv6 routers 605 and middleboxes should support: 607 o TELNET ([RFC0854]): TELNET should be disabled by default, but 608 should be available for operational purposes as required or as 609 configured by the operator 611 o SSH ([RFC4253]): SSH should be the default access for IPv6 capable 612 routers 614 o All network devices supporting IPv6 must support zccess through an 615 Ethernet management port 617 3.3. Supporting Zero Touch Provisioning for Connected Devices 619 To operate a network at scale, operators rely on protocols and 620 mechanisms that reduce provisioning time to a minimum. The preferred 621 state is zero touch provisioning; plug a new router in and it just 622 works without any manual configuration. The closer an operator can 623 come to this ideal, the more MTBM and Operational Expenses (OPEX) can 624 be reduced -- important goals in the real world. IPv6 routers should 625 support several standards, including, but not limited to: 627 o [I-D.ietf-dhc-rfc3315bis]: Dynamic Configuration Protocol for IPv6 628 must be supported. 630 o [RFC4862]: IPv6 Stateless Address Autoconfiguration (SLAAC) must 631 be supported, and must be enabled by default on all router 632 interfaces. SLAAC must be able to be disabled by operators who 633 prefer to use some other mechanism for address management and 634 assignment (specifically for customer facing edge ports). 636 o [RFC7217]: Semantically Opaque Interface Identifiers should be 637 supported unless there's a need to embed MAC address. 639 o [RFC7934]: Host Address Availability, the ability to assign 640 multiple addresses to a host, should be supported. 642 o [RFC7527]: Enhanced Duplicate Address Detection should be 643 supported. 645 o [RFC7527]: Enhanced Duplicate Address Detection may be disabled 646 for manually configured interfaces. 648 o [RFC8028]: First-Hop Router Selection by Hosts, specifically 649 section 2.1, which says a router should be able to send a PIO with 650 both the L and A bits cleared. 652 o [RFC3810]: Routers supporting IPv6 must support Multicast Listener 653 Discovery Version 2 655 o [RFC7772]: Routers supporting IPv6 should support Reducing Energy 656 Consumption of Router Advertisements 658 o [RFC8273]: Routers supporting IPv6 should support Unique IPv6 659 Prefix per Host 661 The provisioning of Domain Name Systems (DNS) system information is a 662 contentious topic, based on provider, operating system, interface, 663 and other requirements. This document therefore addresses the 664 mechanisms that must be included in IPv6 router implementations, but 665 leaves the option of what to configure and deploy to the network 666 operator. Routers supporting IPv6, and intended for user facing 667 connections, must support: 669 o [RFC3646]: DNS Configuration options for Dynamic Host 670 Configuration Protocol for IPv6 (DHCPv6) if DHCPv6 is supported. 672 o [RFC8106]: IPv6 Router Advertisement Options for DNS 673 Configuration. This includes the ability to send Router 674 Advertisements (RAs) with DNS information. 676 Whether these are enabled by default, or require extra configuration, 677 is left as an exercise for providers and implementation developers to 678 determine on a case by case basis. 680 3.4. Device Protection against Denial of Service Attacks 682 Denial of Service (DoS) and Distributed Denial of Service (DDoS) 683 attacks are unfortunately common in the Internet globally; these 684 types of attacks cost network operators a great deal in opportunity 685 and operational costs in prevention and responses. To provide for 686 effective counters to DoS and DDoS attacks directly on routers: 688 o Manufacturers and system integrators should test and clearly 689 report the packet/traffic load handling capabilities of devices 690 with and without various encryption methods enabled 692 o Routers should be able to police traffic destined to the control 693 plane based on the rate of traffic received, including the ability 694 to police individual flows, targeted services, etc., at individual 695 rates as described in [RFC6192] 697 o Ideally, devices should be able to statefully filter traffic 698 destined to the control plane 700 There are other useful techniques for dealing with DDoS attacks at 701 the network level, including: transferring sessions to a new address 702 and abandoning the address under attack, using BGP communities to 703 spread the attack over multiple ingress ports and "consume" it, and 704 requiring mutual authentication before allocating larger resource 705 pools to a connection. These techniques are not "device level," and 706 hence are not considered further here. 708 4. Requirements Related to Telemetry 710 Telemetry relates to information devices push to systems used to 711 monitor and track the state of the network. This applies to 712 individual devices as well as the network as a system. Two major 713 challenges face operators in the area of telemetry: 715 o Information that is laid out primarily for human, rather than 716 machine, consumption. While human consumption of telemetry is 717 important in some situations, this information should be supplied 718 in a form that focuses on machine readability with an overlay or 719 interpretor that allows human consumption. 721 o Software systems that require information to be queried (or polled 722 or even pushed) on a per-item basis. This form of organization 723 can produce a lot of information, and a lot of individual packets, 724 very quickly, overwhelming monitoring systems and consuming a 725 large amount of available network resources. Instead, telemetry 726 should be focused on bulk collection. 728 There are three broad categories of telemetry: device state and 729 traceability, topology state and traceability, and flow traceability. 730 These three roughly correspond to the management plane, the control 731 plane, and the forwarding plane of the network. Each of the sections 732 below considers one of these three telemetry types. 734 4.1. Device State and Traceablity 736 Ideally, the entire network could be monitored using a single 737 modeling language to ease implementation of telemetry systems and 738 increase the pace at which new software can be deployed in production 739 environments. In real deployments, it is often impossible to reach 740 this ideal; however, reducing the languages and methods used, while 741 focusing on machine readability, can greatly ease the deployment and 742 management of a large-scale network. Specifically, IPv6 routers 743 should support: 745 o [RFC6241] and [RFC8040]: NETCONF/RESTCONF transporting telemetry 746 formatted according to YANG (see above) 748 o [I-D.ietf-i2rs-yang-l2-network-topology]: An I2RS model for layer 749 2 topologies 751 o [I-D.ietf-netconf-yang-push]: YANG Datastore Subscription 753 o [RFC5424]: Syslog 755 o gRPC based telemetry interfaces [GRPC] 757 o Simple Network Management Protocol (SNMP) MIBs as appropriate 759 Syslog and SNMP access for telemetry should be considered "legacy," 760 and should not be the focus of new telemetry access development 761 efforts. 763 4.2. Topology State and Traceability 765 IPv6 routers are part of a system of devices that, combined, make up 766 the entire network. Viewing the network as a system is often crucial 767 for operational purposes. For instance, being able to understand 768 changes in the topology and utilization of a network can lead to 769 insights about traffic flow and network growth that lead to a greater 770 understanding of how the network is operating, where problems are 771 developing, and how to improve the network's performance. To support 772 systemic monitoring of the network topology, IPv6 devices should 773 support at least: 775 o [RFC5424]: North-Bound Distribution of Link-State and Traffic 776 Engineering (TE) Information using BGP 778 o [I-D.ietf-i2rs-yang-l2-network-topology]: An I2RS model for layer 779 2 topologies 781 o [RFC8346]: An I2RS model for layer 3 topologies 783 o [RFC8345]: A Data Model for Network Topologies 785 4.3. Flow State and Traceability 787 Network operators frequently need to observe and understand the 788 types, sources, and destinations of traffic passing through devices. 789 For example, information about traffic flows may be used to identify 790 abuse (such as DDOS attacks) or to plan network expansions based on 791 traffic patterns. To support insight and analysis of this traffic, 792 IPv6 devices should support IPFIX as described in [RFC7011], PSAMP as 793 described in [RFC5474], or some other flow state mechanism. 795 In-situ Operational and Management (iOAM) is a technology that being 796 developed at the time of this writing; see [I-D.ietf-ippm-ioam-data]. 797 Operators and vendors should consider the deployment of iOAM to 798 provide deeper information about flow and topology information. 800 5. Requirements Related to IPv6 Forwarding and Addressing 802 There are a number of capabilities that a device should have to be 803 deployed into an IPv6 network, and several forwarding plane 804 considerations operators and vendors need to bear in mind. The 805 sections below explain these considerations. 807 5.1. The IPv6 Address is not a Host Identifier 809 The IPv6 address is commonly treated as a host identifier; it is not. 810 Rather, it is an interface identifier that describes the topological 811 point where a particular host connects to the Internet. 812 Specifically: 814 o The IPv6 address will change when a device changes where it 815 connects to the network. 817 o A single host can have multiple addresses. For instance, a host 818 may have one address per interface, or multiple addresses assigned 819 through different mechanisms, or through multiple connection 820 points. 822 o A single IPv6 address may represent many hosts, as in the case of 823 a group of hosts reachable through a multicast address, or a set 824 of services reachable through an anycast address. 826 Because the host address may change at any time, it is generally 827 harmful to embed IPv6 addresses inside upper layer headers to 828 identify a particular host. 830 5.2. Router IPv6 Addresses 832 Internet Routing Registries may allocate a network operator a wide 833 range of prefix lengths (see [RFC6177] for further information). 834 Within this allocation, network operators will often suballocate 835 address space along nibble boundaries (/48, /52, /56, /60, and /64) 836 for ease of configuration and management. Several common practices 837 are: 839 o Each multiaccess interface is allocated a /64 841 o Point-to-point links are allocated a /64, but should be addressed 842 with a longer prefix length to prevent certain kinds of denial of 843 service attacks ([RFC6547] originally mandated 64 bit prefix 844 lengths on point-to-point links; [RFC6164] explains possible 845 security issues with assigning a 64 bit prefix length to a point- 846 to-point, and recommends a /127 instead) 848 o Although aggregation is typically only performed to the nibble 849 boundaries noted above, variances are possible 851 o Loopback addresses are assigned a /128 853 Given these common practices, routers designed to run IPv6 should 854 support the following addressing conventions: 856 o The default prefix length on any interface other than a loopback 857 should be a /64 859 o Configuring a prefix length longer than a /64 on any multi-access 860 interface should require additional configuration steps to prevent 861 manual configuration errors 863 o Routers must not assume IPv6 prefix lengths only on nibble 864 boundaries 866 o Routers should support any prefix length shorter or greater than 867 /64 869 o Loopback interfaces should default to a /128 prefix length unless 870 some additional configuration is undertaken to override this 871 default setting 873 o Routers must be able to generate link local addresses on all links 874 and/or interfaces using stateless address autoconfiguration (see 875 [RFC6434]). 877 5.3. The Maximum Transmission Unit 879 The long history of the Maximum Transmission Unit (MTU) in networks 880 is not a happy one. Specific problems with MTU sizing include: 882 o Many different default sizes on different media types, from very 883 small (576 bytes on X.25) to very large (17914 bytes on 16Mbps 884 Token Ring) 886 o Many different ways to calculate the MTU on any given link; for 887 instance a 9000 byte MTU can be calculated as 8184 bytes on one 888 operating system, 8972 on another, and 9000 on a third 890 o The increasing use of tunnel encapsulations in the network; for 891 instance MPLS over GRE over IP over... 893 o The wide variety of default MTUs across many different end hosts 894 and operating systems 896 o The general ineffectiveness of path MTU discovery to operate 897 correctly in the face of packet filters and rate limiters (see the 898 section on ICMP filtering below) 900 o Lower speed links at the network edge which require a lot of time 901 to serialize a packet with a large MTU 903 o Increased jitter caused by the disparity between large and small 904 packet size across a lower bandwidth links 906 The final point requires some further elucidation. The time required 907 to serialize various packets at various speeds are: 909 o 64 byte packet onto a 10Mb/s link: .5ms 911 o 1500 byte packet onto a 10Mb/s link: 1.2ms 913 o 9000 byte packet onto a 10Mb/s link: 7.2ms 914 o 64 byte packet onto a 100Mb/s link: .05ms 916 o 1500 byte packet onto a 100Mb/s link: .12ms 918 o 9000 byte packet onto a 100Mb/s link: .72ms 920 A 64 byte packet trapped behind a single 1500 byte packet on a 10Mb/s 921 link suffers 1.2ms of serialization delay. Each additional 1500 byte 922 packet added to the queue in front of the 64 byte packet adds and 923 additional 1.2ms of delay. In contrast, a 64 byte packet trapped 924 behind a single 9000 byte packet on a 10Mb/s link suffers 7.7ms of 925 serialization delay. Each additional 9000 byte packet added to the 926 queue adds an additional 7.2ms of serialization delay. The practical 927 result is that larger MTU sizes on lower speed links can add a 928 significant amount of delay and jitter into a flow. On the other 929 hand, increasing the MTU on higher speed links appears to add 930 negligible additional delay and jitter. 932 The result is that it costs less in terms of overall systemic 933 performance to use higher MTUs on higher speed links than on lower 934 speed links. Based on this, increasing the MTU across any particular 935 link may not increase overall end-to-end performance, but can greatly 936 enhance the performance of local applications (such as a local BGP 937 peering session, or a large/long standing elephant flow used to 938 transfer data across a local fabric), while also providing room for 939 tunnel encapsulations to be added with less impact on lower MTU end 940 systems. 942 The general rule of thumb is to assume the largest size MTU should be 943 used on higher speed transit only links in order to support a wide 944 array of available link sizes, default MTUs, and tunnel 945 encapsulations. Routers designed for a network core, data center 946 core, or use on the global Internet should support at least 9000 byte 947 MTUs on all interfaces. MTU detection mechanisms, such as IS-IS 948 hello padding, described in [RFC3719], should be enabled to ensure 949 correct point-to-point MTU configuration. Devices should also 950 support: 952 o [RFC8201]: Path MTU Discovery for IP version 6 954 o [RFC4821]: Packetization Layer Path MTU Discovery 956 5.4. ICMP Considerations 958 Internet Control Message Protocol (ICMP) is described in [RFC0792] 959 and [RFC4443]. ICMP is often used to perform a traceroute through a 960 network (normally by using a TTL expired ICMP message), for Path MTU 961 discovery, and, in IPv6, for autoconfiguration and neighbor 962 discovery. ICMP is often blocked by middleboxes of various kinds 963 and/or ICMP filters configured on the ingress edge of a provider 964 network, most often to prevent the discovery of reachable hosts and 965 network topology. Routers implementing IPv6: 967 o Should rate limit the generation of ICMP echo and echo responses 968 by default (for instance, using a token bucket method as described 969 in [RFC4443]). The device should support the configuration of not 970 generating ICMP echo, echo response, and time exceeded packets to 971 prevent topology discovery. 973 o Should rate limit the generation of ICMP error messages with a 974 token bucket method as described in [RFC4443]. Rate limits should 975 be narrow enough to (a) protect the device's ability to generate 976 packets and (b) reduce the usefulness of ICMP error packets as 977 part of a distributed denial of service attack. Limits should be 978 generous enough to allow successful path MTU discovery and 979 traceroute. For example, in a small/mid-size device, the possible 980 defaults could be bucket size=100, refill rate=100/s. Larger 981 devices can afford more generous rate limits. 983 o Should implement the filtering suggestions in 984 [I-D.gont-opsec-icmp-ingress-filtering] 986 o Should not filter Destination Unreachable or Packet Too Big ICMP 987 error messages by default, as this has negative impacts on many 988 aspects of IPv6 operation, particularly path MTU discovery. 990 There are implications for path MTU discovery and other useful 991 mechanisms in filtering and rate limiting ICMP. The trade-off here 992 is between allowing unlimited ICMP, which would allow path MTU 993 detection to work, or limiting ICMP in a way that prevents negative 994 side effects for individual devices, and hence the operational 995 capabilities of the network as a whole. Operators rightly limit ICMP 996 to reduce the attack surface against their network, as well as the 997 opportunity for "perfect storm" events that inadvertently reduce the 998 capability of routers and middleboxes. Hence ICMP can be treated as 999 "quasi-reliable" in many situations; existence of an ICMP message can 1000 prove, for instance, that a particular host is unreachable. The non- 1001 existence of an ICMP message, however, does not prove a particular 1002 host exists or does not. 1004 5.5. Machine Access to the Forwarding Table 1006 In order to support treating the "network as a whole" as a single 1007 programmable system, it is important for each router have the ability 1008 to directly program forwarding information. This programmatic 1009 interface allows controllers, which are programmed to support 1010 specific business logic and applications, to modify and filter 1011 traffic flows without interfering with the distributed control plane. 1012 While there are several programmatic interfaces available, this 1013 document suggests that the I2RS interface to the RIB be supported in 1014 all IPv6 routers. Specifically, these drafts should be supported to 1015 enable network programmability: 1017 o [I-D.ietf-i2rs-fb-rib-data-model]: Filter-Based RIB Data Model 1019 o [I-D.ietf-i2rs-fb-rib-info-model]: Filter-Based RIB Information 1020 Model 1022 o [I-D.ietf-i2rs-rib-data-model]: A YANG Data Model for Routing 1023 Information Base (RIB) 1025 o [RFC7922]: I2RS Traceability 1027 5.6. Processing IPv6 Extension Headers 1029 (To be added) 1031 5.7. IPv6 Operation by Default 1033 If a device forwards and/or originates IPv4 packets by default 1034 (without explicit configuration by the operator), it should forward 1035 and/or originate IPv6 packets by default. See the security 1036 considerations section below for reflections on the automatic 1037 configuration of IPv6 forwarding in parallel with IPv4. 1039 5.8. IPv6 Only Operation 1041 While the transition to IPv6 only networks may take years (or perhaps 1042 decades), a number of operators are moving to deploy IPv6 on internal 1043 networks supporting transport and data center fabric applications 1044 more quickly. Routers and middleboxes that support IPv6 should 1045 support IPv6 only operation, including: 1047 o Link Local addressing must be configurable and usable as the 1048 primary address on all interfaces on a device. 1050 o IPv4 and/or MPLS should not be required for proper device 1051 operation. For instance, an IPv4 address should not be required 1052 to determine the router ID for any protocol. See [RFC6540] 1053 section 2. 1055 o Any control plane protocol implementations must support the 1056 recommendations in [RFC7404] for operation using link local 1057 addresses only. 1059 5.9. Prefix Length Handling in IPv6 Packet Forwarding 1061 Routers must support IPv6 destination lookups in the forwarding 1062 process on a single bit prefix length increments, in accordance with 1063 [RFC7608]. 1065 5.10. IPv6 Mobility Support 1067 Mobile IPv6 [RFC6275] and associated specifications, including 1068 [RFC3776] and [RFC4877] allow a node to change its point of 1069 attachment within the Internet, while maintaining (and using) a 1070 permanent address. All communication using the permanent address 1071 continues to proceed as expected even as the node moves around. At 1072 the present time, Mobile IP has seen only limited implementation. 1073 More usage and deployment experience is needed with mobility before 1074 any specific approach can be recommended for broad implementation in 1075 hosts and routers. Consequently, routers may support [RFC6275] and 1076 associated specifications (these specifications are not required for 1077 IPv6 routers). 1079 6. Security Considerations 1081 This document addresses several ways in which devices designed to 1082 support IPv6 forwarding. Some of the recommendations here are 1083 designed to increase device security; for instance, see the section 1084 on device access. Others may intersect with security, but are not 1085 specifically targeted at security, such as running IPv6 link local 1086 only on links. These are not discussed further here, as they improve 1087 the security stance of the network. Other areas discussed in this 1088 draft are more nuanced. This section gathers the intersection 1089 between operational concerns and security concerns into one place. 1091 ICMP security is already considered in the section on ICMP; it will 1092 not be considered further here. Link local only addressing will 1093 increase security by removing transit only links within the network 1094 as a reachable destination. 1096 6.1. Robustness and Security 1098 Robustness, particularly in the area of error handling, largely 1099 improves security if designed and implemented correctly. Many 1100 attacks take advantage of mistakes in implementations and variations 1101 in protocols. In particular, any feature that is unevenly 1102 implemented among a number of implementations often offers an attack 1103 surface. Hence, reducing protocol complexity helps reduce the 1104 breadth of attack surfaces. 1106 Another point to consider at the intersection of robustness and 1107 security is the issue of monocultures. Monocultures are in and of 1108 themselves a potential attack surface, in that finding a single 1109 failure mode can be exploited to take an entire network (or operator) 1110 down. On the other hand, reducing the number of implementations for 1111 any particular protocol will decrease the set of "random" features 1112 deployed in the network. These two goals will often be opposed to 1113 one another. Network designers and operators need to consider these 1114 two sides of this trade-off, and make an intelligent decision about 1115 how much diversity to implement versus how to control the attack 1116 surface represented by deploying a wide array of implementations. 1118 6.2. Programmable Device Access and Security 1120 Programmable interfaces, including programmable configuration, 1121 telemetry, and machine interface to the routing table, introduce a 1122 large attack surface; operators should be careful to ensure this 1123 attack surface is properly secured. Specifically: 1125 o Prevent external access to any administrative access points used 1126 for device programmability 1128 o Use AAA systems to ensure only valid devices and/or users access 1129 devices 1131 o Rate limit the change rate and protect management interfaces from 1132 DoS and DDoS attacks 1134 Such interfaces should be treated no differently than SSH, SFTP, and 1135 other interfaces available to manage routers and middleboxes. 1137 6.3. Zero Touch Provisioning and Security 1139 Zero touch provisioning opens a new attack surface; insider attackers 1140 can simply install a new device, and assume it will be autoconfigured 1141 into the network. A "simple" solution would be to install door 1142 locks, but this will likely not be enough; defenses need to be 1143 layered to be effective. It is recommended that devices installed in 1144 the network need to contain a hardware or software identification 1145 system that allows the operator to identify devices that are 1146 installed in the network. 1148 6.4. Defaulting to IPv6 Forwarding and Security 1150 Operators should be aware that devices which forward IPv6 by default 1151 can introduce a new attack surface or new threats without explicit 1152 configuration. Operators should verify that IPv6 policies, including 1153 filtering, match or fulfill the same intent as any existing IPv4 1154 policies when deploying devices capable of forwarding both IPv4 and 1155 IPv6. 1157 7. IANA Considerations 1159 This document has no actions for IANA. 1161 8. Conclusion 1163 The deployment of IPv6 throughout the Internet marks a point in time 1164 where it is good to review the overall Internet architecture, and 1165 assess the impact on operations of these changes. This document 1166 provides an overview of a lot of these changes and lessons learned, 1167 as well as providing pointers to many of the relevant documents to 1168 understand each topic more deeply. 1170 9. References 1172 9.1. Normative References 1174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1175 Requirement Levels", BCP 14, RFC 2119, 1176 DOI 10.17487/RFC2119, March 1997, 1177 . 1179 9.2. Informative References 1181 [COMPLEXHARD] 1182 Alderson, D. and J. Doyle, "Contrasting Views of 1183 Complexity and Their Implications For Network-Centric 1184 Infrastructures", 2010, 1185 . 1188 [COMPLEXLAYER] 1189 Meyer, D., "Macro Trends, Architecture, and the Hidden 1190 Nature of Complexity", 2010, 1191 . 1194 [DoD] Wikipedia, "The Internet Protocol Suite", 2016, 1195 . 1197 [GRPC] gRPC, "gRPC", 2016, . 1199 [I-D.gont-opsec-icmp-ingress-filtering] 1200 Gont, F., Hunter, R., Massar, J., and W. LIU, "Defeating 1201 Attacks which employ Forged ICMPv4/ICMPv6 Error Messages", 1202 draft-gont-opsec-icmp-ingress-filtering-03 (work in 1203 progress), July 2017. 1205 [I-D.ietf-dhc-rfc3315bis] 1206 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1207 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1208 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 1209 bis", draft-ietf-dhc-rfc3315bis-13 (work in progress), 1210 April 2018. 1212 [I-D.ietf-i2rs-fb-rib-data-model] 1213 Hares, S., Kini, S., Dunbar, L., Krishnan, R., Bogdanovic, 1214 D., and R. White, "Filter-Based RIB Data Model", draft- 1215 ietf-i2rs-fb-rib-data-model-01 (work in progress), March 1216 2017. 1218 [I-D.ietf-i2rs-fb-rib-info-model] 1219 Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, 1220 R., Bogdanovic, D., and R. White, "Filter-Based RIB 1221 Information Model", draft-ietf-i2rs-fb-rib-info-model-00 1222 (work in progress), June 2016. 1224 [I-D.ietf-i2rs-rib-data-model] 1225 Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 1226 S., and N. Bahadur, "A YANG Data Model for Routing 1227 Information Base (RIB)", draft-ietf-i2rs-rib-data-model-15 1228 (work in progress), May 2018. 1230 [I-D.ietf-i2rs-yang-l2-network-topology] 1231 Dong, J. and X. Wei, "A YANG Data Model for Layer-2 1232 Network Topologies", draft-ietf-i2rs-yang-l2-network- 1233 topology-04 (work in progress), March 2018. 1235 [I-D.ietf-ippm-ioam-data] 1236 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 1237 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 1238 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 1239 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 1240 data-02 (work in progress), March 2018. 1242 [I-D.ietf-netconf-yang-push] 1243 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1244 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 1245 Subscription", draft-ietf-netconf-yang-push-15 (work in 1246 progress), February 2018. 1248 [LEAKYABS] 1249 Spolsky, J., "The Law of Leaky Abstractions", 2002, 1250 . 1253 [OPENCONF] 1254 OpenConfig, "Openconfig release YANG models", 2016, 1255 . 1258 [OSI] Wikipedia, "OSI Model", 2016, 1259 . 1261 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1262 RFC 792, DOI 10.17487/RFC0792, September 1981, 1263 . 1265 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 1266 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1267 1983, . 1269 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1270 Communication Layers", STD 3, RFC 1122, 1271 DOI 10.17487/RFC1122, October 1989, 1272 . 1274 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 1275 RFC 1812, DOI 10.17487/RFC1812, June 1995, 1276 . 1278 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1279 and E. Lear, "Address Allocation for Private Internets", 1280 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1281 . 1283 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 1284 Guidelines and Philosophy", RFC 3439, 1285 DOI 10.17487/RFC3439, December 2002, 1286 . 1288 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1289 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1290 DOI 10.17487/RFC3646, December 2003, 1291 . 1293 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 1294 Networks using Intermediate System to Intermediate System 1295 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 1296 . 1298 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1299 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1300 Home Agents", RFC 3776, DOI 10.17487/RFC3776, June 2004, 1301 . 1303 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1304 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1305 DOI 10.17487/RFC3810, June 2004, 1306 . 1308 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1309 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1310 January 2006, . 1312 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1313 Control Message Protocol (ICMPv6) for the Internet 1314 Protocol Version 6 (IPv6) Specification", STD 89, 1315 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1316 . 1318 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1319 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1320 . 1322 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1323 Address Autoconfiguration", RFC 4862, 1324 DOI 10.17487/RFC4862, September 2007, 1325 . 1327 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1328 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1329 DOI 10.17487/RFC4877, April 2007, 1330 . 1332 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 1333 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1334 . 1336 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 1337 DOI 10.17487/RFC5424, March 2009, 1338 . 1340 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., 1341 Grossglauser, M., and J. Rexford, "A Framework for Packet 1342 Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, 1343 March 2009, . 1345 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1346 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1347 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 1348 . 1350 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1351 Assignment to End Sites", BCP 157, RFC 6177, 1352 DOI 10.17487/RFC6177, March 2011, 1353 . 1355 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1356 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1357 March 2011, . 1359 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1360 and A. Bierman, Ed., "Network Configuration Protocol 1361 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1362 . 1364 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1365 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1366 2011, . 1368 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1369 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 1370 2011, . 1372 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1373 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1374 RFC 6540, DOI 10.17487/RFC6540, April 2012, 1375 . 1377 [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, 1378 DOI 10.17487/RFC6547, February 2012, 1379 . 1381 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1382 "Specification of the IP Flow Information Export (IPFIX) 1383 Protocol for the Exchange of Flow Information", STD 77, 1384 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1385 . 1387 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1388 Interface Identifiers with IPv6 Stateless Address 1389 Autoconfiguration (SLAAC)", RFC 7217, 1390 DOI 10.17487/RFC7217, April 2014, 1391 . 1393 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1394 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1395 . 1397 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1398 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1399 2014, . 1401 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 1402 Addressing inside an IPv6 Network", RFC 7404, 1403 DOI 10.17487/RFC7404, November 2014, 1404 . 1406 [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., 1407 and W. George, "Enhanced Duplicate Address Detection", 1408 RFC 7527, DOI 10.17487/RFC7527, April 2015, 1409 . 1411 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 1412 Length Recommendation for Forwarding", BCP 198, RFC 7608, 1413 DOI 10.17487/RFC7608, July 2015, 1414 . 1416 [RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the 1417 IAB Workshop on Stack Evolution in a Middlebox Internet 1418 (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, 1419 . 1421 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 1422 Consumption of Router Advertisements", BCP 202, RFC 7772, 1423 DOI 10.17487/RFC7772, February 2016, 1424 . 1426 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1427 the Routing System (I2RS) Traceability: Framework and 1428 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 1429 2016, . 1431 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 1432 "Host Address Availability Recommendations", BCP 204, 1433 RFC 7934, DOI 10.17487/RFC7934, July 2016, 1434 . 1436 [RFC7980] Behringer, M., Retana, A., White, R., and G. Huston, "A 1437 Framework for Defining Network Complexity", RFC 7980, 1438 DOI 10.17487/RFC7980, October 2016, 1439 . 1441 [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", 1442 RFC 7991, DOI 10.17487/RFC7991, December 2016, 1443 . 1445 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 1446 Hosts in a Multi-Prefix Network", RFC 8028, 1447 DOI 10.17487/RFC8028, November 2016, 1448 . 1450 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1451 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1452 . 1454 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1455 "IPv6 Router Advertisement Options for DNS Configuration", 1456 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1457 . 1459 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 1460 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 1461 May 2017, . 1463 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1464 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1465 DOI 10.17487/RFC8201, July 2017, 1466 . 1468 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1469 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1470 . 1472 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1473 and R. Wilton, "Network Management Datastore Architecture 1474 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1475 . 1477 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1478 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1479 . 1481 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1482 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1483 . 1485 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1486 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1487 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1488 2018, . 1490 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1491 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1492 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1493 March 2018, . 1495 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1496 Routing Management (NMDA Version)", RFC 8349, 1497 DOI 10.17487/RFC8349, March 2018, 1498 . 1500 Authors' Addresses 1502 Zaid Ali Kahn (editor) 1503 LinkedIn 1504 CA 1505 USA 1507 Email: zaid@linkedin.com 1509 John Brzozowski (editor) 1510 Comcast 1511 USA 1513 Email: John_Brzozowski@comcast.com 1515 Russ White (editor) 1516 LinkedIn 1517 Oak Island, NC 28465 1518 USA 1520 Email: russ@riw.us