idnits 2.17.1 draft-ietf-netmod-routing-cfg-24.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 == Line 2406 has weird spacing: '...-prefix ine...' == Line 2423 has weird spacing: '...-prefix ine...' == Line 2452 has weird spacing: '...ro type ide...' == Line 2453 has weird spacing: '...ro name str...' == Line 2457 has weird spacing: '...-family ide...' -- The document date (October 20, 2016) is 2745 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group L. Lhotka 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track A. Lindem 5 Expires: April 23, 2017 Cisco Systems 6 October 20, 2016 8 A YANG Data Model for Routing Management 9 draft-ietf-netmod-routing-cfg-24 11 Abstract 13 This document contains a specification of three YANG modules and one 14 submodule. Together they form the core routing data model which 15 serves as a framework for configuring and managing a routing 16 subsystem. It is expected that these modules will be augmented by 17 additional YANG modules defining data models for control plane 18 protocols, route filters and other functions. The core routing data 19 model provides common building blocks for such extensions -- routes, 20 routing information bases (RIB), and control plane protocols. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 23, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4 58 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 5 59 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 61 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. The Design of the Core Routing Data Model . . . . . . . . . . 7 63 4.1. System-Controlled and User-Controlled List Entries . . . 8 64 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.2. Routing Information Base (RIB) . . . . . . . . . . . . . 9 67 5.3. Control Plane Protocol . . . . . . . . . . . . . . . . . 10 68 5.3.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 10 69 5.3.2. Defining New Control Plane Protocols . . . . . . . . 11 70 5.4. Parameters of IPv6 Router Advertisements . . . . . . . . 12 71 6. Interactions with Other YANG Modules . . . . . . . . . . . . 13 72 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 13 73 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 13 74 7. Routing Management YANG Module . . . . . . . . . . . . . . . 14 75 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 26 76 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 32 77 9.1. IPv6 Router Advertisements Submodule . . . . . . . . . . 37 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 80 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 82 13.1. Normative References . . . . . . . . . . . . . . . . . . 50 83 13.2. Informative References . . . . . . . . . . . . . . . . . 50 84 Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 51 85 A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 51 86 A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 53 87 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 54 88 Appendix C. Example: Adding a New Control Plane Protocol . . . . 54 89 Appendix D. Data Tree Example . . . . . . . . . . . . . . . . . 57 90 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 65 91 E.1. Changes Between Versions -22 and -23 . . . . . . . . . . 65 92 E.2. Changes Between Versions -22 and -23 . . . . . . . . . . 65 93 E.3. Changes Between Versions -21 and -22 . . . . . . . . . . 65 94 E.4. Changes Between Versions -20 and -21 . . . . . . . . . . 66 95 E.5. Changes Between Versions -19 and -20 . . . . . . . . . . 66 96 E.6. Changes Between Versions -18 and -19 . . . . . . . . . . 66 97 E.7. Changes Between Versions -17 and -18 . . . . . . . . . . 66 98 E.8. Changes Between Versions -16 and -17 . . . . . . . . . . 67 99 E.9. Changes Between Versions -15 and -16 . . . . . . . . . . 67 100 E.10. Changes Between Versions -14 and -15 . . . . . . . . . . 68 101 E.11. Changes Between Versions -13 and -14 . . . . . . . . . . 68 102 E.12. Changes Between Versions -12 and -13 . . . . . . . . . . 68 103 E.13. Changes Between Versions -11 and -12 . . . . . . . . . . 69 104 E.14. Changes Between Versions -10 and -11 . . . . . . . . . . 69 105 E.15. Changes Between Versions -09 and -10 . . . . . . . . . . 69 106 E.16. Changes Between Versions -08 and -09 . . . . . . . . . . 70 107 E.17. Changes Between Versions -07 and -08 . . . . . . . . . . 70 108 E.18. Changes Between Versions -06 and -07 . . . . . . . . . . 70 109 E.19. Changes Between Versions -05 and -06 . . . . . . . . . . 70 110 E.20. Changes Between Versions -04 and -05 . . . . . . . . . . 71 111 E.21. Changes Between Versions -03 and -04 . . . . . . . . . . 72 112 E.22. Changes Between Versions -02 and -03 . . . . . . . . . . 72 113 E.23. Changes Between Versions -01 and -02 . . . . . . . . . . 73 114 E.24. Changes Between Versions -00 and -01 . . . . . . . . . . 73 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 117 1. Introduction 119 This document contains a specification of the following YANG modules: 121 o Module "ietf-routing" provides generic components of a routing 122 data model. 124 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 125 module with additional data specific to IPv4 unicast. 127 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 128 module with additional data specific to IPv6 unicast. Its 129 submodule "ietf-ipv6-router-advertisements" also augments the 130 "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277] modules with 131 IPv6 router configuration variables required by [RFC4861]. 133 These modules together define the so-called core routing data model, 134 which is intended as a basis for future data model development 135 covering more sophisticated routing systems. While these three 136 modules can be directly used for simple IP devices with static 137 routing (see Appendix B), their main purpose is to provide essential 138 building blocks for more complicated data models involving multiple 139 control plane protocols, multicast routing, additional address 140 families, and advanced functions such as route filtering or policy 141 routing. To this end, it is expected that the core routing data 142 model will be augmented by numerous modules developed by other IETF 143 working groups. 145 2. Terminology and Notation 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 The following terms are defined in [RFC6241]: 153 o client, 155 o message, 157 o protocol operation, 159 o server. 161 The following terms are defined in [RFC7950]: 163 o action, 165 o augment, 167 o configuration data, 169 o container, 171 o container with presence, 173 o data model, 175 o data node, 177 o feature, 179 o leaf, 181 o list, 183 o mandatory node, 185 o module, 187 o schema tree, 189 o state data, 191 o RPC operation. 193 2.1. Glossary of New Terms 195 core routing data model: YANG data model comprising "ietf-routing", 196 "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing" 197 modules. 199 direct route: a route to a directly connected network. 201 routing information base (RIB): An object containing a list of 202 routes together with other information. See Section 5.2 for 203 details. 205 system-controlled entry: An entry of a list in state data ("config 206 false") that is created by the system independently of what has 207 been explicitly configured. See Section 4.1 for details. 209 user-controlled entry: An entry of a list in state data ("config 210 false") that is created and deleted as a direct consequence of 211 certain configuration changes. See Section 4.1 for details. 213 2.2. Tree Diagrams 215 A simplified graphical representation of the complete data tree is 216 presented in Appendix A, and similar diagrams of its various subtrees 217 appear in the main text. 219 o Brackets "[" and "]" enclose list keys. 221 o Curly braces "{" and "}" contain names of optional features that 222 make the corresponding node conditional. 224 o Abbreviations before data node names: "rw" means configuration 225 (read-write), "ro" state data (read-only), "-x" RPC operations or 226 actions, and "-n" notifications. 228 o Symbols after data node names: "?" means an optional node, "!" a 229 container with presence, and "*" denotes a "list" or "leaf-list". 231 o Parentheses enclose choice and case nodes, and case nodes are also 232 marked with a colon (":"). 234 o Ellipsis ("...") stands for contents of subtrees that are not 235 shown. 237 2.3. Prefixes in Data Node Names 239 In this document, names of data nodes, actions and other data model 240 objects are often used without a prefix, as long as it is clear from 241 the context in which YANG module each name is defined. Otherwise, 242 names are prefixed using the standard prefix associated with the 243 corresponding YANG module, as shown in Table 1. 245 +--------+---------------------------+-----------+ 246 | Prefix | YANG module | Reference | 247 +--------+---------------------------+-----------+ 248 | if | ietf-interfaces | [RFC7223] | 249 | ip | ietf-ip | [RFC7277] | 250 | rt | ietf-routing | Section 7 | 251 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 252 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 253 | yang | ietf-yang-types | [RFC6991] | 254 | inet | ietf-inet-types | [RFC6991] | 255 +--------+---------------------------+-----------+ 257 Table 1: Prefixes and corresponding YANG modules 259 3. Objectives 261 The initial design of the core routing data model was driven by the 262 following objectives: 264 o The data model should be suitable for the common address families, 265 in particular IPv4 and IPv6, and for unicast and multicast 266 routing, as well as Multiprotocol Label Switching (MPLS). 268 o A simple IP routing system, such as one that uses only static 269 routing, should be configurable in a simple way, ideally without 270 any need to develop additional YANG modules. 272 o On the other hand, the core routing framework must allow for 273 complicated implementations involving multiple routing information 274 bases (RIB) and multiple control plane protocols, as well as 275 controlled redistributions of routing information. 277 o Device vendors will want to map the data models built on this 278 generic framework to their proprietary data models and 279 configuration interfaces. Therefore, the framework should be 280 flexible enough to facilitate such a mapping and accommodate data 281 models with different logic. 283 4. The Design of the Core Routing Data Model 285 The core routing data model consists of three YANG modules and one 286 submodule. The first module, "ietf-routing", defines the generic 287 components of a routing system. The other two modules, "ietf-ipv4- 288 unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf- 289 routing" module with additional data nodes that are needed for IPv4 290 and IPv6 unicast routing, respectively. Module "ietf-ipv6-unicast- 291 routing" has a submodule, "ietf-ipv6-router-advertisements", that 292 augments the "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277] 293 modules with configuration variables for IPv6 router advertisements 294 as required by [RFC4861]. Figures 1 and 2 show abridged views of the 295 configuration and state data hierarchies. See Appendix A for the 296 complete data trees. 298 +--rw routing 299 +--rw router-id? 300 +--rw control-plane-protocols 301 | +--rw control-plane-protocol* [type name] 302 | +--rw type 303 | +--rw name 304 | +--rw description? 305 | +--rw static-routes 306 | +--rw v6ur:ipv6 307 | | ... 308 | +--rw v4ur:ipv4 309 | ... 310 +--rw ribs 311 +--rw rib* [name] 312 +--rw name 313 +--rw address-family? 314 +--rw description? 316 Figure 1: Configuration data hierarchy. 318 +--ro routing-state 319 +--ro router-id? 320 +--ro interfaces 321 | +--ro interface* 322 +--ro control-plane-protocols 323 | +--ro control-plane-protocol* [type name] 324 | +--ro type 325 | +--ro name 326 +--ro ribs 327 +--ro rib* [name] 328 +--ro name 329 +--ro address-family 330 +--ro default-rib? 331 +--ro routes 332 | +--ro route* 333 | ... 335 Figure 2: State data hierarchy. 337 As can be seen from Figures 1 and 2, the core routing data model 338 introduces several generic components of a routing framework: routes, 339 RIBs containing lists of routes, and control plane protocols. 340 Section 5 describes these components in more detail. 342 4.1. System-Controlled and User-Controlled List Entries 344 The core routing data model defines several lists in the schema tree, 345 such as "rib", that have to be populated with at least one entry in 346 any properly functioning device, and additional entries may be 347 configured by a client. 349 In such a list, the server creates the required item as a so-called 350 system-controlled entry in state data, i.e., inside the "routing- 351 state" container. 353 An example can be seen in Appendix D: the "/routing-state/ribs/rib" 354 list has two system-controlled entries named "ipv4-master" and 355 "ipv6-master". 357 Additional entries may be created in the configuration by a client, 358 e.g., via the NETCONF protocol. These are so-called user-controlled 359 entries. If the server accepts a configured user-controlled entry, 360 then this entry also appears in the state data version of the list. 362 Corresponding entries in both versions of the list (in state data and 363 configuration) have the same value of the list key. 365 A client may also provide supplemental configuration of system- 366 controlled entries. To do so, the client creates a new entry in the 367 configuration with the desired contents. In order to bind this entry 368 to the corresponding entry in the state data list, the key of the 369 configuration entry has to be set to the same value as the key of the 370 state entry. 372 Deleting a user-controlled entry from the configuration list results 373 in the removal of the corresponding entry in the state data list. In 374 contrast, if a system-controlled entry is deleted from the 375 configuration list, only the extra configuration specified in that 376 entry is removed but the corresponding state data entry remains in 377 the list. 379 5. Basic Building Blocks 381 This section describes the essential components of the core routing 382 data model. 384 5.1. Route 386 Routes are basic elements of information in a routing system. The 387 core routing data model defines only the following minimal set of 388 route attributes: 390 o "destination-prefix": address prefix specifying the set of 391 destination addresses for which the route may be used. This 392 attribute is mandatory. 394 o "route-preference": an integer value (also known as administrative 395 distance) that is used for selecting a preferred route among 396 routes with the same destination prefix. A lower value means a 397 more preferred route. 399 o "next-hop": determines the outgoing interface and/or next-hop 400 address(es), other operation to be performed with a packet. 402 Routes are primarily state data that appear as entries of RIBs 403 (Section 5.2) but they may also be found in configuration data, for 404 example as manually configured static routes. In the latter case, 405 configurable route attributes are generally a subset of attributes 406 defined for RIB routes. 408 5.2. Routing Information Base (RIB) 410 Every implementation of the core routing data model manages one or 411 more routing information bases (RIB). A RIB is a list of routes 412 complemented with administrative data. Each RIB contains only routes 413 of one address family. An address family is represented by an 414 identity derived from the "rt:address-family" base identity. 416 In the core routing data model, RIBs are state data represented as 417 entries of the list "/routing-state/ribs/rib". The contents of RIBs 418 are controlled and manipulated by control plane protocol operations 419 which may result in route additions, removals and modifications. 420 This also includes manipulations via the "static" and/or "direct" 421 pseudo-protocols, see Section 5.3.1. 423 For every supported address family, exactly one RIB MUST be marked as 424 the so-called default RIB. Its role is explained in Section 5.3. 426 Simple router implementations that do not advertise the feature 427 "multiple-ribs" will typically create one system-controlled RIB per 428 supported address family, and mark it as the default RIB. 430 More complex router implementations advertising the "multiple-ribs" 431 feature support multiple RIBs per address family that can be used for 432 policy routing and other purposes. 434 The following action (see Section 7.15 of [RFC7950]) is defined for 435 the "rib" list: 437 o active-route -- return the active RIB route for the destination 438 address that is specified as the action's input parameter. 440 5.3. Control Plane Protocol 442 The core routing data model provides an open-ended framework for 443 defining multiple control plane protocol instances, e.g., for Layer 3 444 routing protocols. Each control plane protocol instance MUST be 445 assigned a type, which is an identity derived from the "rt:control- 446 plane-protocol" base identity. The core routing data model defines 447 two identities for the direct and static pseudo-protocols 448 (Section 5.3.1). 450 Multiple control plane protocol instances of the same type MAY be 451 configured. 453 5.3.1. Routing Pseudo-Protocols 455 The core routing data model defines two special routing protocol 456 types -- "direct" and "static". Both are in fact pseudo-protocols, 457 which means that they are confined to the local device and do not 458 exchange any routing information with adjacent routers. 460 Every implementation of the core routing data model MUST provide 461 exactly one instance of the "direct" pseudo-protocol type. It is the 462 source of direct routes for all configured address families. Direct 463 routes are normally supplied by the operating system kernel, based on 464 the configuration of network interface addresses, see Section 6.2. 466 A pseudo-protocol of the type "static" allows for specifying routes 467 manually. It MAY be configured in zero or multiple instances, 468 although a typical configuration will have exactly one instance. 470 5.3.2. Defining New Control Plane Protocols 472 It is expected that future YANG modules will create data models for 473 additional control plane protocol types. Such a new module has to 474 define the protocol-specific configuration and state data, and it has 475 to integrate it into the core routing framework in the following way: 477 o A new identity MUST be defined for the control plane protocol and 478 its base identity MUST be set to "rt:control-plane-protocol", or 479 to an identity derived from "rt:control-plane-protocol". 481 o Additional route attributes MAY be defined, preferably in one 482 place by means of defining a YANG grouping. The new attributes 483 have to be inserted by augmenting the definitions of the nodes 485 /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 487 and 489 /rt:routing-state/rt:ribs/rt:rib/rt:output/rt:route, 491 and possibly other places in the configuration, state data, 492 notifications, and input/output parameters of actions or RPC 493 operations. 495 o Configuration parameters and/or state data for the new protocol 496 can be defined by augmenting the "control-plane-protocol" data 497 node under both "/routing" and "/routing-state". 499 By using a "when" statement, the augmented configuration parameters 500 and state data specific to the new protocol SHOULD be made 501 conditional and valid only if the value of "rt:type" or "rt:source- 502 protocol" is equal to (or derived from) the new protocol's identity. 504 It is also RECOMMENDED that protocol-specific data nodes be 505 encapsulated in an appropriately named container with presence. Such 506 a container may contain mandatory data nodes that are otherwise 507 forbidden at the top level of an augment. 509 The above steps are implemented by the example YANG module for the 510 RIP routing protocol in Appendix C. 512 5.4. Parameters of IPv6 Router Advertisements 514 YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is 515 a submodule of the "ietf-ipv6-unicast-routing" module, augments the 516 configuration and state data of IPv6 interfaces with definitions of 517 the following variables as required by [RFC4861], sec. 6.2.1: 519 o send-advertisements, 521 o max-rtr-adv-interval, 523 o min-rtr-adv-interval, 525 o managed-flag, 527 o other-config-flag, 529 o link-mtu, 531 o reachable-time, 533 o retrans-timer, 535 o cur-hop-limit, 537 o default-lifetime, 539 o prefix-list: a list of prefixes to be advertised. 541 The following parameters are associated with each prefix in the 542 list: 544 * valid-lifetime, 546 * on-link-flag, 548 * preferred-lifetime, 550 * autonomous-flag. 552 NOTES: 554 1. The "IsRouter" flag, which is also required by [RFC4861], is 555 implemented in the "ietf-ip" module [RFC7277] (leaf 556 "ip:forwarding"). 558 2. The original specification [RFC4861] allows the implementations 559 to decide whether the "valid-lifetime" and "preferred-lifetime" 560 parameters remain the same in consecutive advertisements, or 561 decrement in real time. However, the latter behavior seems 562 problematic because the values might be reset again to the 563 (higher) configured values after a configuration is reloaded. 564 Moreover, no implementation is known to use the decrementing 565 behavior. The "ietf-ipv6-router-advertisements" submodule 566 therefore stipulates the former behavior with constant values. 568 6. Interactions with Other YANG Modules 570 The semantics of the core routing data model also depends on several 571 configuration parameters that are defined in other YANG modules. 573 6.1. Module "ietf-interfaces" 575 The following boolean switch is defined in the "ietf-interfaces" YANG 576 module [RFC7223]: 578 /if:interfaces/if:interface/if:enabled 580 If this switch is set to "false" for a network layer interface, 581 then all routing and forwarding functions MUST be disabled on that 582 interface. 584 6.2. Module "ietf-ip" 586 The following boolean switches are defined in the "ietf-ip" YANG 587 module [RFC7277]: 589 /if:interfaces/if:interface/ip:ipv4/ip:enabled 591 If this switch is set to "false" for a network layer interface, 592 then all IPv4 routing and forwarding functions MUST be disabled on 593 that interface. 595 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 597 If this switch is set to "false" for a network layer interface, 598 then the forwarding of IPv4 datagrams through this interface MUST 599 be disabled. However, the interface MAY participate in other IPv4 600 routing functions, such as routing protocols. 602 /if:interfaces/if:interface/ip:ipv6/ip:enabled 603 If this switch is set to "false" for a network layer interface, 604 then all IPv6 routing and forwarding functions MUST be disabled on 605 that interface. 607 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 609 If this switch is set to "false" for a network layer interface, 610 then the forwarding of IPv6 datagrams through this interface MUST 611 be disabled. However, the interface MAY participate in other IPv6 612 routing functions, such as routing protocols. 614 In addition, the "ietf-ip" module allows for configuring IPv4 and 615 IPv6 addresses and network prefixes or masks on network layer 616 interfaces. Configuration of these parameters on an enabled 617 interface MUST result in an immediate creation of the corresponding 618 direct route. The destination prefix of this route is set according 619 to the configured IP address and network prefix/mask, and the 620 interface is set as the outgoing interface for that route. 622 7. Routing Management YANG Module 624 RFC Editor: In this section, replace all occurrences of 'XXXX' with 625 the actual RFC number and all occurrences of the revision date below 626 with the date of RFC publication (and remove this note). 628 file "ietf-routing@2016-10-20.yang" 630 module ietf-routing { 632 yang-version "1.1"; 634 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 636 prefix "rt"; 638 import ietf-yang-types { 639 prefix "yang"; 640 } 642 import ietf-interfaces { 643 prefix "if"; 644 } 646 organization 647 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 649 contact 650 "WG Web: 651 WG List: 653 WG Chair: Lou Berger 654 656 WG Chair: Kent Watsen 657 659 Editor: Ladislav Lhotka 660 662 Editor: Acee Lindem 663 "; 665 description 666 "This YANG module defines essential components for the management 667 of a routing subsystem. 669 Copyright (c) 2016 IETF Trust and the persons identified as 670 authors of the code. All rights reserved. 672 Redistribution and use in source and binary forms, with or 673 without modification, is permitted pursuant to, and subject to 674 the license terms contained in, the Simplified BSD License set 675 forth in Section 4.c of the IETF Trust's Legal Provisions 676 Relating to IETF Documents 677 (https://trustee.ietf.org/license-info). 679 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 680 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 681 'OPTIONAL' in the module text are to be interpreted as described 682 in RFC 2119 (https://tools.ietf.org/html/rfc2119). 684 This version of this YANG module is part of RFC XXXX 685 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 686 full legal notices."; 688 revision 2016-10-20 { 689 description 690 "Initial revision."; 691 reference 692 "RFC XXXX: A YANG Data Model for Routing Management"; 693 } 695 /* Features */ 697 feature multiple-ribs { 698 description 699 "This feature indicates that the server supports user-defined 700 RIBs. 702 Servers that do not advertise this feature SHOULD provide 703 exactly one system-controlled RIB per supported address family 704 and make them also the default RIBs. These RIBs then appear as 705 entries of the list /routing-state/ribs/rib."; 706 } 708 feature router-id { 709 description 710 "This feature indicates that the server supports configuration 711 of an explicit 32-bit router ID that is used by some routing 712 protocols. 714 Servers that do not advertise this feature set a router ID 715 algorithmically, usually to one of configured IPv4 addresses. 716 However, this algorithm is implementation-specific."; 717 } 719 /* Identities */ 721 identity address-family { 722 description 723 "Base identity from which identities describing address 724 families are derived."; 725 } 727 identity ipv4 { 728 base address-family; 729 description 730 "This identity represents IPv4 address family."; 731 } 733 identity ipv6 { 734 base address-family; 735 description 736 "This identity represents IPv6 address family."; 737 } 739 identity control-plane-protocol { 740 description 741 "Base identity from which control plane protocol identities are 742 derived."; 743 } 745 identity routing-protocol { 746 base control-plane-protocol; 747 description 748 "Identity from which Layer 3 routing protocol identities are 749 derived."; 750 } 752 identity direct { 753 base routing-protocol; 754 description 755 "Routing pseudo-protocol that provides routes to directly 756 connected networks."; 757 } 759 identity static { 760 base routing-protocol; 761 description 762 "Static routing pseudo-protocol."; 763 } 765 /* Type Definitions */ 767 typedef route-preference { 768 type uint32; 769 description 770 "This type is used for route preferences."; 771 } 773 /* Groupings */ 775 grouping address-family { 776 description 777 "This grouping provides a leaf identifying an address 778 family."; 779 leaf address-family { 780 type identityref { 781 base address-family; 782 } 783 mandatory "true"; 784 description 785 "Address family."; 786 } 787 } 789 grouping router-id { 790 description 791 "This grouping provides router ID."; 792 leaf router-id { 793 type yang:dotted-quad; 794 description 795 "A 32-bit number in the form of a dotted quad that is used by 796 some routing protocols identifying a router."; 797 reference 798 "RFC 2328: OSPF Version 2."; 799 } 800 } 802 grouping special-next-hop { 803 description 804 "This grouping provides a leaf with an enumeration of special 805 next-hops."; 806 leaf special-next-hop { 807 type enumeration { 808 enum blackhole { 809 description 810 "Silently discard the packet."; 811 } 812 enum unreachable { 813 description 814 "Discard the packet and notify the sender with an error 815 message indicating that the destination host is 816 unreachable."; 817 } 818 enum prohibit { 819 description 820 "Discard the packet and notify the sender with an error 821 message indicating that the communication is 822 administratively prohibited."; 823 } 824 enum receive { 825 description 826 "The packet will be received by the local system."; 827 } 828 } 829 description 830 "Special next-hop options."; 831 } 832 } 834 grouping next-hop-content { 835 description 836 "Generic parameters of next-hops in static routes."; 837 choice next-hop-options { 838 mandatory "true"; 839 description 840 "Options for next-hops in static routes. 842 It is expected that further cases will be added through 843 augments from other modules."; 844 case simple-next-hop { 845 description 846 "This case represents a simple next hop consisting of the 847 next-hop address and/or outgoing interface. 849 Modules for address families MUST augment this case with a 850 leaf containing a next-hop address of that address 851 family."; 852 leaf outgoing-interface { 853 type if:interface-ref; 854 description 855 "Name of the outgoing interface."; 856 } 857 } 858 case special-next-hop { 859 uses special-next-hop; 860 } 861 case next-hop-list { 862 container next-hop-list { 863 description 864 "Container for multiple next-hops."; 865 list next-hop { 866 key "index"; 867 description 868 "An entry of a next-hop list. 870 Modules for address families MUST augment this list 871 with a leaf containing a next-hop address of that 872 address family."; 873 leaf index { 874 type string; 875 description 876 "An user-specified identifier utilised to uniquely 877 reference the next-hop entry in the next-hop list. 878 The value of this index has no semantic meaning 879 other than for referencing the entry."; 880 } 881 leaf outgoing-interface { 882 type if:interface-ref; 883 description 884 "Name of the outgoing interface."; 885 } 886 } 887 } 888 } 889 } 890 } 891 grouping next-hop-state-content { 892 description 893 "Generic parameters of next-hops in state data."; 894 choice next-hop-options { 895 mandatory "true"; 896 description 897 "Options for next-hops in state data. 899 It is expected that further cases will be added through 900 augments from other modules, e.g., for recursive 901 next-hops."; 902 case simple-next-hop { 903 description 904 "This case represents a simple next hop consisting of the 905 next-hop address and/or outgoing interface. 907 Modules for address families MUST augment this case with a 908 leaf containing a next-hop address of that address 909 family."; 910 leaf outgoing-interface { 911 type if:interface-state-ref; 912 description 913 "Name of the outgoing interface."; 914 } 915 } 916 case special-next-hop { 917 uses special-next-hop; 918 } 919 case next-hop-list { 920 container next-hop-list { 921 description 922 "Container for multiple next-hops."; 923 list next-hop { 924 description 925 "An entry of a next-hop list. 927 Modules for address families MUST augment this list 928 with a leaf containing a next-hop address of that 929 address family."; 930 leaf outgoing-interface { 931 type if:interface-state-ref; 932 description 933 "Name of the outgoing interface."; 934 } 935 } 936 } 937 } 938 } 940 } 942 grouping route-metadata { 943 description 944 "Common route metadata."; 945 leaf source-protocol { 946 type identityref { 947 base routing-protocol; 948 } 949 mandatory "true"; 950 description 951 "Type of the routing protocol from which the route 952 originated."; 953 } 954 leaf active { 955 type empty; 956 description 957 "Presence of this leaf indicates that the route is preferred 958 among all routes in the same RIB that have the same 959 destination prefix."; 960 } 961 leaf last-updated { 962 type yang:date-and-time; 963 description 964 "Time stamp of the last modification of the route. If the 965 route was never modified, it is the time when the route was 966 inserted into the RIB."; 967 } 968 } 970 /* State data */ 972 container routing-state { 973 config "false"; 974 description 975 "State data of the routing subsystem."; 976 uses router-id { 977 description 978 "Global router ID. 980 It may be either configured or assigned algorithmically by 981 the implementation."; 982 } 983 container interfaces { 984 description 985 "Network layer interfaces used for routing."; 986 leaf-list interface { 987 type if:interface-state-ref; 988 description 989 "Each entry is a reference to the name of a configured 990 network layer interface."; 991 } 992 } 993 container control-plane-protocols { 994 description 995 "Container for the list of routing protocol instances."; 996 list control-plane-protocol { 997 key "type name"; 998 description 999 "State data of a control plane protocol instance. 1001 An implementation MUST provide exactly one 1002 system-controlled instance of the 'direct' 1003 pseudo-protocol. Instances of other control plane 1004 protocols MAY be created by configuration."; 1005 leaf type { 1006 type identityref { 1007 base control-plane-protocol; 1008 } 1009 description 1010 "Type of the control plane protocol."; 1011 } 1012 leaf name { 1013 type string; 1014 description 1015 "The name of the control plane protocol instance. 1017 For system-controlled instances this name is persistent, 1018 i.e., it SHOULD NOT change across reboots."; 1019 } 1020 } 1021 } 1022 container ribs { 1023 description 1024 "Container for RIBs."; 1025 list rib { 1026 key "name"; 1027 min-elements "1"; 1028 description 1029 "Each entry represents a RIB identified by the 'name' key. 1030 All routes in a RIB MUST belong to the same address 1031 family. 1033 An implementation SHOULD provide one system-controlled 1034 default RIB for each supported address family."; 1035 leaf name { 1036 type string; 1037 description 1038 "The name of the RIB."; 1039 } 1040 uses address-family; 1041 leaf default-rib { 1042 if-feature "multiple-ribs"; 1043 type boolean; 1044 default "true"; 1045 description 1046 "This flag has the value of 'true' if and only if the RIB 1047 is the default RIB for the given address family. 1049 By default, control plane protocols place their routes 1050 in the default RIBs."; 1051 } 1052 container routes { 1053 description 1054 "Current content of the RIB."; 1055 list route { 1056 description 1057 "A RIB route entry. This data node MUST be augmented 1058 with information specific for routes of each address 1059 family."; 1060 leaf route-preference { 1061 type route-preference; 1062 description 1063 "This route attribute, also known as administrative 1064 distance, allows for selecting the preferred route 1065 among routes with the same destination prefix. A 1066 smaller value means a more preferred route."; 1067 } 1068 container next-hop { 1069 description 1070 "Route's next-hop attribute."; 1071 uses next-hop-state-content; 1072 } 1073 uses route-metadata; 1074 } 1075 } 1076 action active-route { 1077 description 1078 "Return the active RIB route that is used for the 1079 destination address. 1081 Address family specific modules MUST augment input 1082 parameters with a leaf named 'destination-address'."; 1083 output { 1084 container route { 1085 description 1086 "The active RIB route for the specified destination. 1088 If no route exists in the RIB for the destination 1089 address, no output is returned. 1091 Address family specific modules MUST augment this 1092 container with appropriate route contents."; 1093 container next-hop { 1094 description 1095 "Route's next-hop attribute."; 1096 uses next-hop-state-content; 1097 } 1098 uses route-metadata; 1099 } 1100 } 1101 } 1102 } 1103 } 1104 } 1106 /* Configuration Data */ 1108 container routing { 1109 description 1110 "Configuration parameters for the routing subsystem."; 1111 uses router-id { 1112 if-feature "router-id"; 1113 description 1114 "Configuration of the global router ID. Routing protocols 1115 that use router ID can use this parameter or override it 1116 with another value."; 1117 } 1118 container control-plane-protocols { 1119 description 1120 "Configuration of control plane protocol instances."; 1121 list control-plane-protocol { 1122 key "type name"; 1123 description 1124 "Each entry contains configuration of a control plane 1125 protocol instance."; 1126 leaf type { 1127 type identityref { 1128 base control-plane-protocol; 1129 } 1130 description 1131 "Type of the control plane protocol - an identity derived 1132 from the 'control-plane-protocol' base identity."; 1133 } 1134 leaf name { 1135 type string; 1136 description 1137 "An arbitrary name of the control plane protocol 1138 instance."; 1139 } 1140 leaf description { 1141 type string; 1142 description 1143 "Textual description of the control plane protocol 1144 instance."; 1145 } 1146 container static-routes { 1147 when "derived-from-or-self(../type, 'rt:static')" { 1148 description 1149 "This container is only valid for the 'static' routing 1150 protocol."; 1151 } 1152 description 1153 "Configuration of the 'static' pseudo-protocol. 1155 Address-family-specific modules augment this node with 1156 their lists of routes."; 1157 } 1158 } 1159 } 1160 container ribs { 1161 description 1162 "Configuration of RIBs."; 1163 list rib { 1164 key "name"; 1165 description 1166 "Each entry contains configuration for a RIB identified by 1167 the 'name' key. 1169 Entries having the same key as a system-controlled entry 1170 of the list /routing-state/ribs/rib are used for 1171 configuring parameters of that entry. Other entries define 1172 additional user-controlled RIBs."; 1173 leaf name { 1174 type string; 1175 description 1176 "The name of the RIB. 1178 For system-controlled entries, the value of this leaf 1179 must be the same as the name of the corresponding entry 1180 in state data. 1182 For user-controlled entries, an arbitrary name can be 1183 used."; 1184 } 1185 uses address-family { 1186 description 1187 "Address family of the RIB. 1189 It is mandatory for user-controlled RIBs. For 1190 system-controlled RIBs it can be omitted, otherwise it 1191 must match the address family of the corresponding state 1192 entry."; 1193 refine "address-family" { 1194 mandatory "false"; 1195 } 1196 } 1197 leaf description { 1198 type string; 1199 description 1200 "Textual description of the RIB."; 1201 } 1202 } 1203 } 1204 } 1205 } 1207 1209 8. IPv4 Unicast Routing Management YANG Module 1211 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1212 the actual RFC number and all occurrences of the revision date below 1213 with the date of RFC publication (and remove this note). 1215 file "ietf-ipv4-unicast-routing@2016-10-20.yang" 1217 module ietf-ipv4-unicast-routing { 1219 yang-version "1.1"; 1221 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1223 prefix "v4ur"; 1225 import ietf-routing { 1226 prefix "rt"; 1227 } 1228 import ietf-inet-types { 1229 prefix "inet"; 1230 } 1232 organization 1233 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1235 contact 1236 "WG Web: 1237 WG List: 1239 WG Chair: Lou Berger 1240 1242 WG Chair: Kent Watsen 1243 1245 Editor: Ladislav Lhotka 1246 1248 Editor: Acee Lindem 1249 "; 1251 description 1252 "This YANG module augments the 'ietf-routing' module with basic 1253 configuration and state data for IPv4 unicast routing. 1255 Copyright (c) 2016 IETF Trust and the persons identified as 1256 authors of the code. All rights reserved. 1258 Redistribution and use in source and binary forms, with or 1259 without modification, is permitted pursuant to, and subject to 1260 the license terms contained in, the Simplified BSD License set 1261 forth in Section 4.c of the IETF Trust's Legal Provisions 1262 Relating to IETF Documents 1263 (https://trustee.ietf.org/license-info). 1265 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1266 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1267 'OPTIONAL' in the module text are to be interpreted as described 1268 in RFC 2119 (https://tools.ietf.org/html/rfc2119). 1270 This version of this YANG module is part of RFC XXXX 1271 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1272 full legal notices."; 1274 revision 2016-10-20 { 1275 description 1276 "Initial revision."; 1277 reference 1278 "RFC XXXX: A YANG Data Model for Routing Management"; 1279 } 1281 /* Identities */ 1283 identity ipv4-unicast { 1284 base rt:ipv4; 1285 description 1286 "This identity represents the IPv4 unicast address family."; 1287 } 1289 /* State data */ 1291 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1292 when "derived-from-or-self(../../rt:address-family, " 1293 + "'v4ur:ipv4-unicast')" { 1294 description 1295 "This augment is valid only for IPv4 unicast."; 1296 } 1297 description 1298 "This leaf augments an IPv4 unicast route."; 1299 leaf destination-prefix { 1300 type inet:ipv4-prefix; 1301 description 1302 "IPv4 destination prefix."; 1303 } 1304 } 1306 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1307 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1308 when "derived-from-or-self(../../../rt:address-family, " 1309 + "'v4ur:ipv4-unicast')" { 1310 description 1311 "This augment is valid only for IPv4 unicast."; 1312 } 1313 description 1314 "Augment 'simple-next-hop' case in IPv4 unicast routes."; 1315 leaf next-hop-address { 1316 type inet:ipv4-address; 1317 description 1318 "IPv4 address of the next-hop."; 1319 } 1320 } 1322 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1323 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1324 + "rt:next-hop-list/rt:next-hop" { 1325 when "derived-from-or-self(../../../../../rt:address-family, " 1326 + "'v4ur:ipv4-unicast')" { 1327 description 1328 "This augment is valid only for IPv4 unicast."; 1329 } 1330 description 1331 "This leaf augments the 'next-hop-list' case of IPv4 unicast 1332 routes."; 1333 leaf address { 1334 type inet:ipv4-address; 1335 description 1336 "IPv4 address of the next-hop."; 1337 } 1338 } 1340 augment 1341 "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" { 1342 when "derived-from-or-self(../rt:address-family, " 1343 + "'v4ur:ipv4-unicast')" { 1344 description 1345 "This augment is valid only for IPv4 unicast RIBs."; 1346 } 1347 description 1348 "This augment adds the input parameter of the 'active-route' 1349 action."; 1350 leaf destination-address { 1351 type inet:ipv4-address; 1352 description 1353 "IPv4 destination address."; 1354 } 1355 } 1357 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1358 + "rt:output/rt:route" { 1359 when "derived-from-or-self(../../rt:address-family, " 1360 + "'v4ur:ipv4-unicast')" { 1361 description 1362 "This augment is valid only for IPv4 unicast."; 1363 } 1364 description 1365 "This augment adds the destination prefix to the reply of the 1366 'active-route' action."; 1367 leaf destination-prefix { 1368 type inet:ipv4-prefix; 1369 description 1370 "IPv4 destination prefix."; 1371 } 1373 } 1375 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1376 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1377 + "rt:simple-next-hop" { 1378 when "derived-from-or-self(../../../rt:address-family, " 1379 + "'v4ur:ipv4-unicast')" { 1380 description 1381 "This augment is valid only for IPv4 unicast."; 1382 } 1383 description 1384 "Augment 'simple-next-hop' case in the reply to the 1385 'active-route' action."; 1386 leaf next-hop-address { 1387 type inet:ipv4-address; 1388 description 1389 "IPv4 address of the next-hop."; 1390 } 1391 } 1393 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1394 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1395 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1396 when "derived-from-or-self(../../../../../rt:address-family, " 1397 + "'v4ur:ipv4-unicast')" { 1398 description 1399 "This augment is valid only for IPv4 unicast."; 1400 } 1401 description 1402 "Augment 'next-hop-list' case in the reply to the 1403 'active-route' action."; 1404 leaf next-hop-address { 1405 type inet:ipv4-address; 1406 description 1407 "IPv4 address of the next-hop."; 1408 } 1409 } 1411 /* Configuration data */ 1413 augment "/rt:routing/rt:control-plane-protocols/" 1414 + "rt:control-plane-protocol/rt:static-routes" { 1415 description 1416 "This augment defines the configuration of the 'static' 1417 pseudo-protocol with data specific to IPv4 unicast."; 1418 container ipv4 { 1419 description 1420 "Configuration of a 'static' pseudo-protocol instance 1421 consists of a list of routes."; 1422 list route { 1423 key "destination-prefix"; 1424 description 1425 "A list of static routes."; 1426 leaf destination-prefix { 1427 type inet:ipv4-prefix; 1428 mandatory "true"; 1429 description 1430 "IPv4 destination prefix."; 1431 } 1432 leaf description { 1433 type string; 1434 description 1435 "Textual description of the route."; 1436 } 1437 container next-hop { 1438 description 1439 "Configuration of next-hop."; 1440 uses rt:next-hop-content { 1441 augment "next-hop-options/simple-next-hop" { 1442 description 1443 "Augment 'simple-next-hop' case in IPv4 static 1444 routes."; 1445 leaf next-hop-address { 1446 type inet:ipv4-address; 1447 description 1448 "IPv4 address of the next-hop."; 1449 } 1450 } 1451 augment "next-hop-options/next-hop-list/next-hop-list/" 1452 + "next-hop" { 1453 description 1454 "Augment 'next-hop-list' case in IPv4 static 1455 routes."; 1456 leaf next-hop-address { 1457 type inet:ipv4-address; 1458 description 1459 "IPv4 address of the next-hop."; 1460 } 1461 } 1462 } 1463 } 1464 } 1465 } 1466 } 1467 } 1468 1470 9. IPv6 Unicast Routing Management YANG Module 1472 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1473 the actual RFC number and all occurrences of the revision date below 1474 with the date of RFC publication (and remove this note). 1476 file "ietf-ipv6-unicast-routing@2016-10-20.yang" 1478 module ietf-ipv6-unicast-routing { 1480 yang-version "1.1"; 1482 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1484 prefix "v6ur"; 1486 import ietf-routing { 1487 prefix "rt"; 1488 } 1490 import ietf-inet-types { 1491 prefix "inet"; 1492 } 1494 include ietf-ipv6-router-advertisements { 1495 revision-date 2016-10-20; 1496 } 1498 organization 1499 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1501 contact 1502 "WG Web: 1503 WG List: 1505 WG Chair: Lou Berger 1506 1508 WG Chair: Kent Watsen 1509 1511 Editor: Ladislav Lhotka 1512 1514 Editor: Acee Lindem 1515 "; 1517 description 1518 "This YANG module augments the 'ietf-routing' module with basic 1519 configuration and state data for IPv6 unicast routing. 1521 Copyright (c) 2016 IETF Trust and the persons identified as 1522 authors of the code. All rights reserved. 1524 Redistribution and use in source and binary forms, with or 1525 without modification, is permitted pursuant to, and subject to 1526 the license terms contained in, the Simplified BSD License set 1527 forth in Section 4.c of the IETF Trust's Legal Provisions 1528 Relating to IETF Documents 1529 (https://trustee.ietf.org/license-info). 1531 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1532 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1533 'OPTIONAL' in the module text are to be interpreted as described 1534 in RFC 2119 (https://tools.ietf.org/html/rfc2119). 1536 This version of this YANG module is part of RFC XXXX 1537 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1538 full legal notices."; 1540 revision 2016-10-20 { 1541 description 1542 "Initial revision."; 1543 reference 1544 "RFC XXXX: A YANG Data Model for Routing Management"; 1545 } 1547 /* Identities */ 1549 identity ipv6-unicast { 1550 base rt:ipv6; 1551 description 1552 "This identity represents the IPv6 unicast address family."; 1553 } 1555 /* State data */ 1557 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1558 when "derived-from-or-self(../../rt:address-family, " 1559 + "'v6ur:ipv6-unicast')" { 1560 description 1561 "This augment is valid only for IPv6 unicast."; 1562 } 1563 description 1564 "This leaf augments an IPv6 unicast route."; 1566 leaf destination-prefix { 1567 type inet:ipv6-prefix; 1568 description 1569 "IPv6 destination prefix."; 1570 } 1571 } 1573 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1574 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1575 when "derived-from-or-self(../../../rt:address-family, " 1576 + "'v6ur:ipv6-unicast')" { 1577 description 1578 "This augment is valid only for IPv6 unicast."; 1579 } 1580 description 1581 "Augment 'simple-next-hop' case in IPv6 unicast routes."; 1582 leaf next-hop-address { 1583 type inet:ipv6-address; 1584 description 1585 "IPv6 address of the next-hop."; 1586 } 1587 } 1589 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1590 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1591 + "rt:next-hop-list/rt:next-hop" { 1592 when "derived-from-or-self(../../../../../rt:address-family, " 1593 + "'v6ur:ipv6-unicast')" { 1594 description 1595 "This augment is valid only for IPv6 unicast."; 1596 } 1597 description 1598 "This leaf augments the 'next-hop-list' case of IPv6 unicast 1599 routes."; 1600 leaf address { 1601 type inet:ipv6-address; 1602 description 1603 "IPv6 address of the next-hop."; 1604 } 1605 } 1607 augment 1608 "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" { 1609 when "derived-from-or-self(../rt:address-family, " 1610 + "'v6ur:ipv6-unicast')" { 1611 description 1612 "This augment is valid only for IPv6 unicast RIBs."; 1613 } 1614 description 1615 "This augment adds the input parameter of the 'active-route' 1616 action."; 1617 leaf destination-address { 1618 type inet:ipv6-address; 1619 description 1620 "IPv6 destination address."; 1621 } 1622 } 1624 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1625 + "rt:output/rt:route" { 1626 when "derived-from-or-self(../../rt:address-family, " 1627 + "'v6ur:ipv6-unicast')" { 1628 description 1629 "This augment is valid only for IPv6 unicast."; 1630 } 1631 description 1632 "This augment adds the destination prefix to the reply of the 1633 'active-route' action."; 1634 leaf destination-prefix { 1635 type inet:ipv6-prefix; 1636 description 1637 "IPv6 destination prefix."; 1638 } 1639 } 1641 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1642 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1643 + "rt:simple-next-hop" { 1644 when "derived-from-or-self(../../../rt:address-family, " 1645 + "'v6ur:ipv6-unicast')" { 1646 description 1647 "This augment is valid only for IPv6 unicast."; 1648 } 1649 description 1650 "Augment 'simple-next-hop' case in the reply to the 1651 'active-route' action."; 1652 leaf next-hop-address { 1653 type inet:ipv6-address; 1654 description 1655 "IPv6 address of the next-hop."; 1656 } 1657 } 1659 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1660 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1661 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1663 when "derived-from-or-self(../../../../../rt:address-family, " 1664 + "'v6ur:ipv6-unicast')" { 1665 description 1666 "This augment is valid only for IPv6 unicast."; 1667 } 1668 description 1669 "Augment 'next-hop-list' case in the reply to the 1670 'active-route' action."; 1671 leaf next-hop-address { 1672 type inet:ipv6-address; 1673 description 1674 "IPv6 address of the next-hop."; 1675 } 1676 } 1678 /* Configuration data */ 1680 augment "/rt:routing/rt:control-plane-protocols/" 1681 + "rt:control-plane-protocol/rt:static-routes" { 1682 description 1683 "This augment defines the configuration of the 'static' 1684 pseudo-protocol with data specific to IPv6 unicast."; 1685 container ipv6 { 1686 description 1687 "Configuration of a 'static' pseudo-protocol instance 1688 consists of a list of routes."; 1689 list route { 1690 key "destination-prefix"; 1691 description 1692 "A list of static routes."; 1693 leaf destination-prefix { 1694 type inet:ipv6-prefix; 1695 mandatory "true"; 1696 description 1697 "IPv6 destination prefix."; 1698 } 1699 leaf description { 1700 type string; 1701 description 1702 "Textual description of the route."; 1703 } 1704 container next-hop { 1705 description 1706 "Configuration of next-hop."; 1707 uses rt:next-hop-content { 1708 augment "next-hop-options/simple-next-hop" { 1709 description 1710 "Augment 'simple-next-hop' case in IPv6 static 1711 routes."; 1712 leaf next-hop-address { 1713 type inet:ipv6-address; 1714 description 1715 "IPv6 address of the next-hop."; 1716 } 1717 } 1718 augment "next-hop-options/next-hop-list/next-hop-list/" 1719 + "next-hop" { 1720 description 1721 "Augment 'next-hop-list' case in IPv6 static 1722 routes."; 1723 leaf next-hop-address { 1724 type inet:ipv6-address; 1725 description 1726 "IPv6 address of the next-hop."; 1727 } 1728 } 1729 } 1730 } 1731 } 1732 } 1733 } 1734 } 1736 1738 9.1. IPv6 Router Advertisements Submodule 1740 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1741 the actual RFC number and all occurrences of the revision date below 1742 with the date of RFC publication (and remove this note). 1744 file "ietf-ipv6-router-advertisements@2016-10-20.yang" 1746 submodule ietf-ipv6-router-advertisements { 1748 yang-version "1.1"; 1750 belongs-to ietf-ipv6-unicast-routing { 1751 prefix "v6ur"; 1752 } 1754 import ietf-inet-types { 1755 prefix "inet"; 1756 } 1758 import ietf-interfaces { 1759 prefix "if"; 1760 } 1762 import ietf-ip { 1763 prefix "ip"; 1764 } 1766 organization 1767 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1769 contact 1770 "WG Web: 1771 WG List: 1773 WG Chair: Lou Berger 1774 1776 WG Chair: Kent Watsen 1777 1779 Editor: Ladislav Lhotka 1780 1782 Editor: Acee Lindem 1783 "; 1785 description 1786 "This YANG module augments the 'ietf-ip' module with 1787 configuration and state data of IPv6 router advertisements. 1789 Copyright (c) 2016 IETF Trust and the persons identified as 1790 authors of the code. All rights reserved. 1792 Redistribution and use in source and binary forms, with or 1793 without modification, is permitted pursuant to, and subject to 1794 the license terms contained in, the Simplified BSD License set 1795 forth in Section 4.c of the IETF Trust's Legal Provisions 1796 Relating to IETF Documents 1797 (https://trustee.ietf.org/license-info). 1799 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1800 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1801 'OPTIONAL' in the module text are to be interpreted as described 1802 in RFC 2119 (https://tools.ietf.org/html/rfc2119). 1804 This version of this YANG module is part of RFC XXXX 1805 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1806 full legal notices."; 1808 reference 1809 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)."; 1811 revision 2016-10-20 { 1812 description 1813 "Initial revision."; 1814 reference 1815 "RFC XXXX: A YANG Data Model for Routing Management"; 1816 } 1818 /* State data */ 1820 augment "/if:interfaces-state/if:interface/ip:ipv6" { 1821 description 1822 "Augment interface state data with parameters of IPv6 router 1823 advertisements."; 1824 container ipv6-router-advertisements { 1825 description 1826 "Parameters of IPv6 Router Advertisements."; 1827 leaf send-advertisements { 1828 type boolean; 1829 description 1830 "A flag indicating whether or not the router sends periodic 1831 Router Advertisements and responds to Router 1832 Solicitations."; 1833 } 1834 leaf max-rtr-adv-interval { 1835 type uint16 { 1836 range "4..1800"; 1837 } 1838 units "seconds"; 1839 description 1840 "The maximum time allowed between sending unsolicited 1841 multicast Router Advertisements from the interface."; 1842 } 1843 leaf min-rtr-adv-interval { 1844 type uint16 { 1845 range "3..1350"; 1846 } 1847 units "seconds"; 1848 description 1849 "The minimum time allowed between sending unsolicited 1850 multicast Router Advertisements from the interface."; 1851 } 1852 leaf managed-flag { 1853 type boolean; 1854 description 1855 "The value that is placed in the 'Managed address 1856 configuration' flag field in the Router Advertisement."; 1857 } 1858 leaf other-config-flag { 1859 type boolean; 1860 description 1861 "The value that is placed in the 'Other configuration' flag 1862 field in the Router Advertisement."; 1863 } 1864 leaf link-mtu { 1865 type uint32; 1866 description 1867 "The value that is placed in MTU options sent by the 1868 router. A value of zero indicates that no MTU options are 1869 sent."; 1870 } 1871 leaf reachable-time { 1872 type uint32 { 1873 range "0..3600000"; 1874 } 1875 units "milliseconds"; 1876 description 1877 "The value that is placed in the Reachable Time field in 1878 the Router Advertisement messages sent by the router. A 1879 value of zero means unspecified (by this router)."; 1880 } 1881 leaf retrans-timer { 1882 type uint32; 1883 units "milliseconds"; 1884 description 1885 "The value that is placed in the Retrans Timer field in the 1886 Router Advertisement messages sent by the router. A value 1887 of zero means unspecified (by this router)."; 1888 } 1889 leaf cur-hop-limit { 1890 type uint8; 1891 description 1892 "The value that is placed in the Cur Hop Limit field in the 1893 Router Advertisement messages sent by the router. A value 1894 of zero means unspecified (by this router)."; 1895 } 1896 leaf default-lifetime { 1897 type uint16 { 1898 range "0..9000"; 1899 } 1900 units "seconds"; 1901 description 1902 "The value that is placed in the Router Lifetime field of 1903 Router Advertisements sent from the interface, in seconds. 1905 A value of zero indicates that the router is not to be 1906 used as a default router."; 1907 } 1908 container prefix-list { 1909 description 1910 "A list of prefixes that are placed in Prefix Information 1911 options in Router Advertisement messages sent from the 1912 interface. 1914 By default, these are all prefixes that the router 1915 advertises via routing protocols as being on-link for the 1916 interface from which the advertisement is sent."; 1917 list prefix { 1918 key "prefix-spec"; 1919 description 1920 "Advertised prefix entry and its parameters."; 1921 leaf prefix-spec { 1922 type inet:ipv6-prefix; 1923 description 1924 "IPv6 address prefix."; 1925 } 1926 leaf valid-lifetime { 1927 type uint32; 1928 units "seconds"; 1929 description 1930 "The value that is placed in the Valid Lifetime in the 1931 Prefix Information option. The designated value of all 1932 1's (0xffffffff) represents infinity. 1934 An implementation SHOULD keep this value constant in 1935 consecutive advertisements except when it is 1936 explicitly changed in configuration."; 1937 } 1938 leaf on-link-flag { 1939 type boolean; 1940 description 1941 "The value that is placed in the on-link flag ('L-bit') 1942 field in the Prefix Information option."; 1943 } 1944 leaf preferred-lifetime { 1945 type uint32; 1946 units "seconds"; 1947 description 1948 "The value that is placed in the Preferred Lifetime in 1949 the Prefix Information option, in seconds. The 1950 designated value of all 1's (0xffffffff) represents 1951 infinity. 1953 An implementation SHOULD keep this value constant in 1954 consecutive advertisements except when it is 1955 explicitly changed in configuration."; 1956 } 1957 leaf autonomous-flag { 1958 type boolean; 1959 description 1960 "The value that is placed in the Autonomous Flag field 1961 in the Prefix Information option."; 1962 } 1963 } 1964 } 1965 } 1966 } 1968 /* Configuration data */ 1970 augment "/if:interfaces/if:interface/ip:ipv6" { 1971 description 1972 "Augment interface configuration with parameters of IPv6 router 1973 advertisements."; 1974 container ipv6-router-advertisements { 1975 description 1976 "Configuration of IPv6 Router Advertisements."; 1977 leaf send-advertisements { 1978 type boolean; 1979 default "false"; 1980 description 1981 "A flag indicating whether or not the router sends periodic 1982 Router Advertisements and responds to Router 1983 Solicitations."; 1984 reference 1985 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1986 AdvSendAdvertisements."; 1987 } 1988 leaf max-rtr-adv-interval { 1989 type uint16 { 1990 range "4..1800"; 1991 } 1992 units "seconds"; 1993 default "600"; 1994 description 1995 "The maximum time allowed between sending unsolicited 1996 multicast Router Advertisements from the interface."; 1997 reference 1998 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1999 MaxRtrAdvInterval."; 2000 } 2001 leaf min-rtr-adv-interval { 2002 type uint16 { 2003 range "3..1350"; 2004 } 2005 units "seconds"; 2006 must ". <= 0.75 * ../max-rtr-adv-interval" { 2007 description 2008 "The value MUST NOT be greater than 75 % of 2009 'max-rtr-adv-interval'."; 2010 } 2011 description 2012 "The minimum time allowed between sending unsolicited 2013 multicast Router Advertisements from the interface. 2015 The default value to be used operationally if this leaf is 2016 not configured is determined as follows: 2018 - if max-rtr-adv-interval >= 9 seconds, the default value 2019 is 0.33 * max-rtr-adv-interval; 2021 - otherwise it is 0.75 * max-rtr-adv-interval."; 2022 reference 2023 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2024 MinRtrAdvInterval."; 2025 } 2026 leaf managed-flag { 2027 type boolean; 2028 default "false"; 2029 description 2030 "The value to be placed in the 'Managed address 2031 configuration' flag field in the Router Advertisement."; 2032 reference 2033 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2034 AdvManagedFlag."; 2035 } 2036 leaf other-config-flag { 2037 type boolean; 2038 default "false"; 2039 description 2040 "The value to be placed in the 'Other configuration' flag 2041 field in the Router Advertisement."; 2042 reference 2043 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2044 AdvOtherConfigFlag."; 2045 } 2046 leaf link-mtu { 2047 type uint32; 2048 default "0"; 2049 description 2050 "The value to be placed in MTU options sent by the router. 2051 A value of zero indicates that no MTU options are sent."; 2052 reference 2053 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2054 AdvLinkMTU."; 2055 } 2056 leaf reachable-time { 2057 type uint32 { 2058 range "0..3600000"; 2059 } 2060 units "milliseconds"; 2061 default "0"; 2062 description 2063 "The value to be placed in the Reachable Time field in the 2064 Router Advertisement messages sent by the router. A value 2065 of zero means unspecified (by this router)."; 2066 reference 2067 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2068 AdvReachableTime."; 2069 } 2070 leaf retrans-timer { 2071 type uint32; 2072 units "milliseconds"; 2073 default "0"; 2074 description 2075 "The value to be placed in the Retrans Timer field in the 2076 Router Advertisement messages sent by the router. A value 2077 of zero means unspecified (by this router)."; 2078 reference 2079 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2080 AdvRetransTimer."; 2081 } 2082 leaf cur-hop-limit { 2083 type uint8; 2084 description 2085 "The value to be placed in the Cur Hop Limit field in the 2086 Router Advertisement messages sent by the router. A value 2087 of zero means unspecified (by this router). 2089 If this parameter is not configured, the device SHOULD use 2090 the value specified in IANA Assigned Numbers that was in 2091 effect at the time of implementation."; 2092 reference 2093 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2094 AdvCurHopLimit. 2096 IANA: IP Parameters, 2097 http://www.iana.org/assignments/ip-parameters"; 2098 } 2099 leaf default-lifetime { 2100 type uint16 { 2101 range "0..9000"; 2102 } 2103 units "seconds"; 2104 description 2105 "The value to be placed in the Router Lifetime field of 2106 Router Advertisements sent from the interface, in seconds. 2107 It MUST be either zero or between max-rtr-adv-interval and 2108 9000 seconds. A value of zero indicates that the router is 2109 not to be used as a default router. These limits may be 2110 overridden by specific documents that describe how IPv6 2111 operates over different link layers. 2113 If this parameter is not configured, the device SHOULD use 2114 a value of 3 * max-rtr-adv-interval."; 2115 reference 2116 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2117 AdvDefaultLifeTime."; 2118 } 2119 container prefix-list { 2120 description 2121 "Configuration of prefixes to be placed in Prefix 2122 Information options in Router Advertisement messages sent 2123 from the interface. 2125 Prefixes that are advertised by default but do not have 2126 their entries in the child 'prefix' list are advertised 2127 with the default values of all parameters. 2129 The link-local prefix SHOULD NOT be included in the list 2130 of advertised prefixes."; 2131 reference 2132 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2133 AdvPrefixList."; 2134 list prefix { 2135 key "prefix-spec"; 2136 description 2137 "Configuration of an advertised prefix entry."; 2138 leaf prefix-spec { 2139 type inet:ipv6-prefix; 2140 description 2141 "IPv6 address prefix."; 2142 } 2143 choice control-adv-prefixes { 2144 default "advertise"; 2145 description 2146 "The prefix either may be explicitly removed from the 2147 set of advertised prefixes, or parameters with which 2148 it is advertised may be specified (default case)."; 2149 leaf no-advertise { 2150 type empty; 2151 description 2152 "The prefix will not be advertised. 2154 This can be used for removing the prefix from the 2155 default set of advertised prefixes."; 2156 } 2157 case advertise { 2158 leaf valid-lifetime { 2159 type uint32; 2160 units "seconds"; 2161 default "2592000"; 2162 description 2163 "The value to be placed in the Valid Lifetime in 2164 the Prefix Information option. The designated 2165 value of all 1's (0xffffffff) represents 2166 infinity."; 2167 reference 2168 "RFC 4861: Neighbor Discovery for IP version 6 2169 (IPv6) - AdvValidLifetime."; 2170 } 2171 leaf on-link-flag { 2172 type boolean; 2173 default "true"; 2174 description 2175 "The value to be placed in the on-link flag 2176 ('L-bit') field in the Prefix Information 2177 option."; 2178 reference 2179 "RFC 4861: Neighbor Discovery for IP version 6 2180 (IPv6) - AdvOnLinkFlag."; 2181 } 2182 leaf preferred-lifetime { 2183 type uint32; 2184 units "seconds"; 2185 must ". <= ../valid-lifetime" { 2186 description 2187 "This value MUST NOT be greater than 2188 valid-lifetime."; 2189 } 2190 default "604800"; 2191 description 2192 "The value to be placed in the Preferred Lifetime 2193 in the Prefix Information option. The designated 2194 value of all 1's (0xffffffff) represents 2195 infinity."; 2196 reference 2197 "RFC 4861: Neighbor Discovery for IP version 6 2198 (IPv6) - AdvPreferredLifetime."; 2199 } 2200 leaf autonomous-flag { 2201 type boolean; 2202 default "true"; 2203 description 2204 "The value to be placed in the Autonomous Flag 2205 field in the Prefix Information option."; 2206 reference 2207 "RFC 4861: Neighbor Discovery for IP version 6 2208 (IPv6) - AdvAutonomousFlag."; 2209 } 2210 } 2211 } 2212 } 2213 } 2214 } 2215 } 2216 } 2218 2220 10. IANA Considerations 2222 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2223 actual RFC number (and remove this note). 2225 This document registers the following namespace URIs in the IETF XML 2226 registry [RFC3688]: 2228 -------------------------------------------------------------------- 2229 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2231 Registrant Contact: The IESG. 2233 XML: N/A, the requested URI is an XML namespace. 2234 -------------------------------------------------------------------- 2235 -------------------------------------------------------------------- 2236 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2238 Registrant Contact: The IESG. 2240 XML: N/A, the requested URI is an XML namespace. 2241 -------------------------------------------------------------------- 2243 -------------------------------------------------------------------- 2244 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2246 Registrant Contact: The IESG. 2248 XML: N/A, the requested URI is an XML namespace. 2249 -------------------------------------------------------------------- 2251 This document registers the following YANG modules in the YANG Module 2252 Names registry [RFC6020]: 2254 -------------------------------------------------------------------- 2255 name: ietf-routing 2256 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2257 prefix: rt 2258 reference: RFC XXXX 2259 -------------------------------------------------------------------- 2261 -------------------------------------------------------------------- 2262 name: ietf-ipv4-unicast-routing 2263 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2264 prefix: v4ur 2265 reference: RFC XXXX 2266 -------------------------------------------------------------------- 2268 -------------------------------------------------------------------- 2269 name: ietf-ipv6-unicast-routing 2270 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2271 prefix: v6ur 2272 reference: RFC XXXX 2273 -------------------------------------------------------------------- 2275 This document registers the following YANG submodule in the YANG 2276 Module Names registry [RFC6020]: 2278 -------------------------------------------------------------------- 2279 name: ietf-ipv6-router-advertisements 2280 parent: ietf-ipv6-unicast-routing 2281 reference: RFC XXXX 2282 -------------------------------------------------------------------- 2284 11. Security Considerations 2286 Configuration and state data conforming to the core routing data 2287 model (defined in this document) are designed to be accessed via a 2288 management protocol with secure transport layer, such as NETCONF 2289 [RFC6241]. The NETCONF access control model [RFC6536] provides the 2290 means to restrict access for particular NETCONF users to a pre- 2291 configured subset of all available NETCONF protocol operations and 2292 content. 2294 A number of configuration data nodes defined in the YANG modules 2295 belonging to the core routing data model are writable/creatable/ 2296 deletable (i.e., "config true" in YANG terms, which is the default). 2297 These data nodes may be considered sensitive or vulnerable in some 2298 network environments. Write operations to these data nodes, such as 2299 "edit-config" in NETCONF, can have negative effects on the network if 2300 the protocol operations are not properly protected. 2302 The vulnerable "config true" parameters and subtrees are the 2303 following: 2305 /routing/control-plane-protocols/control-plane-protocol: This list 2306 specifies the control plane protocols configured on a device. 2308 /routing/ribs/rib: This list specifies the RIBs configured for the 2309 device. 2311 Unauthorised access to any of these lists can adversely affect the 2312 routing subsystem of both the local device and the network. This may 2313 lead to network malfunctions, delivery of packets to inappropriate 2314 destinations and other problems. 2316 12. Acknowledgments 2318 The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean 2319 Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini, 2320 David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane 2321 Litkowski, Thomas Morin, Tom Petch, Yingzhen Qu, Bruno Rijsman, 2322 Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man- 2323 Kit Yeung and Jeffrey Zhang for their helpful comments and 2324 suggestions. 2326 13. References 2327 13.1. Normative References 2329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2330 Requirement Levels", BCP 14, RFC 2119, 2331 DOI 10.17487/RFC2119, March 1997, . 2334 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2335 DOI 10.17487/RFC3688, January 2004, . 2338 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2339 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2340 DOI 10.17487/RFC4861, September 2007, . 2343 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2344 the Network Configuration Protocol (NETCONF)", RFC 6020, 2345 DOI 10.17487/RFC6020, October 2010, . 2348 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2349 and A. Bierman, Ed., "Network Configuration Protocol 2350 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2351 . 2353 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2354 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2355 . 2357 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2358 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2359 . 2361 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 2362 RFC 7277, DOI 10.17487/RFC7277, June 2014, 2363 . 2365 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2366 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2367 . 2369 13.2. Informative References 2371 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2372 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 2373 January 2011, . 2375 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2376 Protocol (NETCONF) Access Control Model", RFC 6536, 2377 DOI 10.17487/RFC6536, March 2012, . 2380 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 2381 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 2382 . 2384 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2385 RFC 7951, DOI 10.17487/RFC7951, August 2016, 2386 . 2388 Appendix A. The Complete Data Trees 2390 This appendix presents the complete configuration and state data 2391 trees of the core routing data model. See Section 2.2 for an 2392 explanation of the symbols used. Data type of every leaf node is 2393 shown near the right end of the corresponding line. 2395 A.1. Configuration Data 2396 +--rw routing 2397 +--rw router-id? yang:dotted-quad 2398 +--rw control-plane-protocols 2399 | +--rw control-plane-protocol* [type name] 2400 | +--rw type identityref 2401 | +--rw name string 2402 | +--rw description? string 2403 | +--rw static-routes 2404 | +--rw v6ur:ipv6 2405 | | +--rw v6ur:route* [destination-prefix] 2406 | | +--rw v6ur:destination-prefix inet:ipv6-prefix 2407 | | +--rw v6ur:description? string 2408 | | +--rw v6ur:next-hop 2409 | | +--rw (v6ur:next-hop-options) 2410 | | +--:(v6ur:simple-next-hop) 2411 | | | +--rw v6ur:outgoing-interface? 2412 | | | +--rw v6ur:next-hop-address? 2413 | | +--:(v6ur:special-next-hop) 2414 | | | +--rw v6ur:special-next-hop? enumeration 2415 | | +--:(v6ur:next-hop-list) 2416 | | +--rw v6ur:next-hop-list 2417 | | +--rw v6ur:next-hop* [index] 2418 | | +--rw v6ur:index string 2419 | | +--rw v6ur:outgoing-interface? 2420 | | +--rw v6ur:next-hop-address? 2421 | +--rw v4ur:ipv4 2422 | +--rw v4ur:route* [destination-prefix] 2423 | +--rw v4ur:destination-prefix inet:ipv4-prefix 2424 | +--rw v4ur:description? string 2425 | +--rw v4ur:next-hop 2426 | +--rw (v4ur:next-hop-options) 2427 | +--:(v4ur:simple-next-hop) 2428 | | +--rw v4ur:outgoing-interface? 2429 | | +--rw v4ur:next-hop-address? 2430 | +--:(v4ur:special-next-hop) 2431 | | +--rw v4ur:special-next-hop? enumeration 2432 | +--:(v4ur:next-hop-list) 2433 | +--rw v4ur:next-hop-list 2434 | +--rw v4ur:next-hop* [index] 2435 | +--rw v4ur:index string 2436 | +--rw v4ur:outgoing-interface? 2437 | +--rw v4ur:next-hop-address? 2438 +--rw ribs 2439 +--rw rib* [name] 2440 +--rw name string 2441 +--rw address-family? identityref 2442 +--rw description? string 2444 A.2. State Data 2446 +--ro routing-state 2447 | +--ro router-id? yang:dotted-quad 2448 | +--ro interfaces 2449 | | +--ro interface* if:interface-state-ref 2450 | +--ro control-plane-protocols 2451 | | +--ro control-plane-protocol* [type name] 2452 | | +--ro type identityref 2453 | | +--ro name string 2454 | +--ro ribs 2455 | +--ro rib* [name] 2456 | +--ro name string 2457 | +--ro address-family identityref 2458 | +--ro default-rib? boolean {multiple-ribs}? 2459 | +--ro routes 2460 | | +--ro route* 2461 | | +--ro route-preference? route-preference 2462 | | +--ro next-hop 2463 | | | +--ro (next-hop-options) 2464 | | | +--:(simple-next-hop) 2465 | | | | +--ro outgoing-interface? 2466 | | | | +--ro v6ur:next-hop-address? 2467 | | | | +--ro v4ur:next-hop-address? 2468 | | | +--:(special-next-hop) 2469 | | | | +--ro special-next-hop? enumeration 2470 | | | +--:(next-hop-list) 2471 | | | +--ro next-hop-list 2472 | | | +--ro next-hop* 2473 | | | +--ro outgoing-interface? 2474 | | | +--ro v6ur:address? 2475 | | | +--ro v4ur:address? 2476 | | +--ro source-protocol identityref 2477 | | +--ro active? empty 2478 | | +--ro last-updated? yang:date-and-time 2479 | | +--ro v6ur:destination-prefix? inet:ipv6-prefix 2480 | | +--ro v4ur:destination-prefix? inet:ipv4-prefix 2481 | +---x active-route 2482 | +---w input 2483 | | +---w v6ur:destination-address? inet:ipv6-address 2484 | | +---w v4ur:destination-address? inet:ipv4-address 2485 | +--ro output 2486 | +--ro route 2487 | +--ro next-hop 2488 | | +--ro (next-hop-options) 2489 | | +--:(simple-next-hop) 2490 | | | +--ro outgoing-interface? 2491 | | | +--ro v6ur:next-hop-address? 2492 | | | +--ro v4ur:next-hop-address? 2493 | | +--:(special-next-hop) 2494 | | | +--ro special-next-hop? enumeration 2495 | | +--:(next-hop-list) 2496 | | +--ro next-hop-list 2497 | | +--ro next-hop* 2498 | | +--ro outgoing-interface? 2499 | | +--ro v6ur:next-hop-address? 2500 | | +--ro v4ur:next-hop-address? 2501 | +--ro source-protocol identityref 2502 | +--ro active? empty 2503 | +--ro last-updated? yang:date-and-time 2504 | +--ro v6ur:destination-prefix? inet:ipv6-prefix 2505 | +--ro v4ur:destination-prefix? inet:ipv4-prefix 2507 Appendix B. Minimum Implementation 2509 Some parts and options of the core routing model, such as user- 2510 defined RIBs, are intended only for advanced routers. This appendix 2511 gives basic non-normative guidelines for implementing a bare minimum 2512 of available functions. Such an implementation may be used for hosts 2513 or very simple routers. 2515 A minimum implementation does not support the feature "multiple- 2516 ribs". This means that a single system-controlled RIB is available 2517 for each supported address family - IPv4, IPv6 or both. These RIBs 2518 are also the default RIBs. No user-controlled RIBs are allowed. 2520 In addition to the mandatory instance of the "direct" pseudo- 2521 protocol, a minimum implementation should support configuring 2522 instance(s) of the "static" pseudo-protocol. 2524 Platforms with severely constrained resources may use deviations for 2525 restricting the data model, e.g., limiting the number of "static" 2526 control plane protocol instances. 2528 Appendix C. Example: Adding a New Control Plane Protocol 2530 This appendix demonstrates how the core routing data model can be 2531 extended to support a new control plane protocol. The YANG module 2532 "example-rip" shown below is intended as an illustration rather than 2533 a real definition of a data model for the RIP routing protocol. For 2534 the sake of brevity, this module does not obey all the guidelines 2535 specified in [RFC6087]. See also Section 5.3.2. 2537 module example-rip { 2539 yang-version "1.1"; 2540 namespace "http://example.com/rip"; 2542 prefix "rip"; 2544 import ietf-interfaces { 2545 prefix "if"; 2546 } 2548 import ietf-routing { 2549 prefix "rt"; 2550 } 2552 identity rip { 2553 base rt:routing-protocol; 2554 description 2555 "Identity for the RIP routing protocol."; 2556 } 2558 typedef rip-metric { 2559 type uint8 { 2560 range "0..16"; 2561 } 2562 } 2564 grouping route-content { 2565 description 2566 "This grouping defines RIP-specific route attributes."; 2567 leaf metric { 2568 type rip-metric; 2569 } 2570 leaf tag { 2571 type uint16; 2572 default "0"; 2573 description 2574 "This leaf may be used to carry additional info, e.g. AS 2575 number."; 2576 } 2577 } 2579 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 2580 when "derived-from-or-self(rt:source-protocol, 'rip:rip')" { 2581 description 2582 "This augment is only valid for a routes whose source 2583 protocol is RIP."; 2584 } 2585 description 2586 "RIP-specific route attributes."; 2587 uses route-content; 2589 } 2591 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 2592 + "rt:output/rt:route" { 2593 description 2594 "RIP-specific route attributes in the output of 'active-route' 2595 RPC."; 2596 uses route-content; 2597 } 2599 augment "/rt:routing/rt:control-plane-protocols/" 2600 + "rt:control-plane-protocol" { 2601 when "derived-from-or-self(rt:type,'rip:rip')" { 2602 description 2603 "This augment is only valid for a routing protocol instance 2604 of type 'rip'."; 2605 } 2606 container rip { 2607 presence "RIP configuration"; 2608 description 2609 "RIP instance configuration."; 2610 container interfaces { 2611 description 2612 "Per-interface RIP configuration."; 2613 list interface { 2614 key "name"; 2615 description 2616 "RIP is enabled on interfaces that have an entry in this 2617 list, unless 'enabled' is set to 'false' for that 2618 entry."; 2619 leaf name { 2620 type if:interface-ref; 2621 } 2622 leaf enabled { 2623 type boolean; 2624 default "true"; 2625 } 2626 leaf metric { 2627 type rip-metric; 2628 default "1"; 2629 } 2630 } 2631 } 2632 leaf update-interval { 2633 type uint8 { 2634 range "10..60"; 2635 } 2636 units "seconds"; 2637 default "30"; 2638 description 2639 "Time interval between periodic updates."; 2640 } 2641 } 2642 } 2643 } 2645 Appendix D. Data Tree Example 2647 This section contains an example instance data tree in the JSON 2648 encoding [RFC7951], containing both configuration and state data. 2649 The data conforms to a data model that is defined by the following 2650 YANG library specification [RFC7895]: 2652 { 2653 "ietf-yang-library:modules-state": { 2654 "module-set-id": "3e9be92f252db56fe912cd61a6f516ecf2f46315", 2655 "module": [ 2656 { 2657 "name": "ietf-routing", 2658 "revision": "2016-10-20", 2659 "feature": [ 2660 "multiple-ribs", 2661 "router-id" 2662 ], 2663 "namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", 2664 "conformance-type": "implement" 2665 }, 2666 { 2667 "name": "ietf-ipv4-unicast-routing", 2668 "revision": "2016-10-20", 2669 "namespace": 2670 "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing", 2671 "conformance-type": "implement" 2672 }, 2673 { 2674 "name": "ietf-ipv6-unicast-routing", 2675 "revision": "2016-10-20", 2676 "namespace": 2677 "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing", 2678 "conformance-type": "implement", 2679 "submodule": [ 2680 { 2681 "name": "ietf-ipv6-router-advertisements", 2682 "revision": "2016-10-20" 2683 } 2684 ] 2686 }, 2687 { 2688 "name": "ietf-interfaces", 2689 "revision": "2014-05-08", 2690 "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", 2691 "conformance-type": "implement" 2692 }, 2693 { 2694 "name": "iana-if-type", 2695 "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type", 2696 "revision": "", 2697 "conformance-type": "implement" 2698 }, 2699 { 2700 "name": "ietf-inet-types", 2701 "revision": "2013-07-15", 2702 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 2703 "conformance-type": "import" 2704 }, 2705 { 2706 "name": "ietf-yang-types", 2707 "revision": "2013-07-15", 2708 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2709 "conformance-type": "import" 2710 }, 2711 { 2712 "name": "ietf-ip", 2713 "revision": "2014-06-16", 2714 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", 2715 "conformance-type": "implement" 2716 } 2717 ] 2718 } 2719 } 2721 A simple network set-up as shown in Figure 3 is assumed: router "A" 2722 uses static default routes with the "ISP" router as the next-hop. 2723 IPv6 router advertisements are configured only on the "eth1" 2724 interface and disabled on the upstream "eth0" interface. 2726 +-----------------+ 2727 | | 2728 | Router ISP | 2729 | | 2730 +--------+--------+ 2731 |2001:db8:0:1::2 2732 |192.0.2.2 2733 | 2734 | 2735 |2001:db8:0:1::1 2736 eth0|192.0.2.1 2737 +--------+--------+ 2738 | | 2739 | Router A | 2740 | | 2741 +--------+--------+ 2742 eth1|198.51.100.1 2743 |2001:db8:0:2::1 2744 | 2746 Figure 3: Example network configuration 2748 The instance data tree could then be as follows: 2750 { 2751 "ietf-interfaces:interfaces": { 2752 "interface": [ 2753 { 2754 "name": "eth0", 2755 "type": "iana-if-type:ethernetCsmacd", 2756 "description": "Uplink to ISP.", 2757 "ietf-ip:ipv4": { 2758 "address": [ 2759 { 2760 "ip": "192.0.2.1", 2761 "prefix-length": 24 2762 } 2763 ], 2764 "forwarding": true 2765 }, 2766 "ietf-ip:ipv6": { 2767 "address": [ 2768 { 2769 "ip": "2001:0db8:0:1::1", 2770 "prefix-length": 64 2771 } 2772 ], 2773 "forwarding": true, 2774 "autoconf": { 2775 "create-global-addresses": false 2776 } 2777 } 2778 }, 2779 { 2780 "name": "eth1", 2781 "type": "iana-if-type:ethernetCsmacd", 2782 "description": "Interface to the internal network.", 2783 "ietf-ip:ipv4": { 2784 "address": [ 2785 { 2786 "ip": "198.51.100.1", 2787 "prefix-length": 24 2788 } 2789 ], 2790 "forwarding": true 2791 }, 2792 "ietf-ip:ipv6": { 2793 "address": [ 2794 { 2795 "ip": "2001:0db8:0:2::1", 2796 "prefix-length": 64 2797 } 2798 ], 2799 "forwarding": true, 2800 "autoconf": { 2801 "create-global-addresses": false 2802 }, 2803 "ietf-ipv6-unicast-routing:ipv6-router-advertisements": { 2804 "send-advertisements": true 2805 } 2806 } 2807 } 2808 ] 2809 }, 2810 "ietf-interfaces:interfaces-state": { 2811 "interface": [ 2812 { 2813 "name": "eth0", 2814 "type": "iana-if-type:ethernetCsmacd", 2815 "phys-address": "00:0C:42:E5:B1:E9", 2816 "oper-status": "up", 2817 "statistics": { 2818 "discontinuity-time": "2015-10-24T17:11:27+02:00" 2819 }, 2820 "ietf-ip:ipv4": { 2821 "forwarding": true, 2822 "mtu": 1500, 2823 "address": [ 2824 { 2825 "ip": "192.0.2.1", 2826 "prefix-length": 24 2827 } 2828 ] 2829 }, 2830 "ietf-ip:ipv6": { 2831 "forwarding": true, 2832 "mtu": 1500, 2833 "address": [ 2834 { 2835 "ip": "2001:0db8:0:1::1", 2836 "prefix-length": 64 2837 } 2838 ], 2839 "ietf-ipv6-unicast-routing:ipv6-router-advertisements": { 2840 "send-advertisements": true, 2841 "prefix-list": { 2842 "prefix": [ 2843 { 2844 "prefix-spec": "2001:db8:0:2::/64" 2845 } 2846 ] 2847 } 2848 } 2849 } 2850 }, 2851 { 2852 "name": "eth1", 2853 "type": "iana-if-type:ethernetCsmacd", 2854 "phys-address": "00:0C:42:E5:B1:EA", 2855 "oper-status": "up", 2856 "statistics": { 2857 "discontinuity-time": "2015-10-24T17:11:29+02:00" 2858 }, 2859 "ietf-ip:ipv4": { 2860 "forwarding": true, 2861 "mtu": 1500, 2862 "address": [ 2863 { 2864 "ip": "198.51.100.1", 2865 "prefix-length": 24 2866 } 2867 ] 2868 }, 2869 "ietf-ip:ipv6": { 2870 "forwarding": true, 2871 "mtu": 1500, 2872 "address": [ 2873 { 2874 "ip": "2001:0db8:0:2::1", 2875 "prefix-length": 64 2876 } 2877 ], 2878 "ietf-ipv6-unicast-routing:ipv6-router-advertisements": { 2879 "send-advertisements": true, 2880 "prefix-list": { 2881 "prefix": [ 2882 { 2883 "prefix-spec": "2001:db8:0:2::/64" 2884 } 2885 ] 2886 } 2887 } 2888 } 2889 } 2890 ] 2891 }, 2892 "ietf-routing:routing": { 2893 "router-id": "192.0.2.1", 2894 "control-plane-protocols": { 2895 "control-plane-protocol": [ 2896 { 2897 "type": "ietf-routing:static", 2898 "name": "st0", 2899 "description": 2900 "Static routing is used for the internal network.", 2901 "static-routes": { 2902 "ietf-ipv4-unicast-routing:ipv4": { 2903 "route": [ 2904 { 2905 "destination-prefix": "0.0.0.0/0", 2906 "next-hop": { 2907 "next-hop-address": "192.0.2.2" 2908 } 2909 } 2910 ] 2911 }, 2912 "ietf-ipv6-unicast-routing:ipv6": { 2913 "route": [ 2914 { 2915 "destination-prefix": "::/0", 2916 "next-hop": { 2917 "next-hop-address": "2001:db8:0:1::2" 2919 } 2920 } 2921 ] 2922 } 2923 } 2924 } 2925 ] 2926 } 2927 }, 2928 "ietf-routing:routing-state": { 2929 "interfaces": { 2930 "interface": [ 2931 "eth0", 2932 "eth1" 2933 ] 2934 }, 2935 "control-plane-protocols": { 2936 "control-plane-protocol": [ 2937 { 2938 "type": "ietf-routing:static", 2939 "name": "st0" 2940 } 2941 ] 2942 }, 2943 "ribs": { 2944 "rib": [ 2945 { 2946 "name": "ipv4-master", 2947 "address-family": "ietf-ipv4-unicast-routing:ipv4-unicast", 2948 "default-rib": true, 2949 "routes": { 2950 "route": [ 2951 { 2952 "ietf-ipv4-unicast-routing:destination-prefix": 2953 "192.0.2.1/24", 2954 "next-hop": { 2955 "outgoing-interface": "eth0" 2956 }, 2957 "route-preference": 0, 2958 "source-protocol": "ietf-routing:direct", 2959 "last-updated": "2015-10-24T17:11:27+02:00" 2960 }, 2961 { 2962 "ietf-ipv4-unicast-routing:destination-prefix": 2963 "198.51.100.0/24", 2964 "next-hop": { 2965 "outgoing-interface": "eth1" 2966 }, 2967 "source-protocol": "ietf-routing:direct", 2968 "route-preference": 0, 2969 "last-updated": "2015-10-24T17:11:27+02:00" 2970 }, 2971 { 2972 "ietf-ipv4-unicast-routing:destination-prefix": 2973 "0.0.0.0/0", 2974 "source-protocol": "ietf-routing:static", 2975 "route-preference": 5, 2976 "next-hop": { 2977 "ietf-ipv4-unicast-routing:next-hop-address": 2978 "192.0.2.2" 2979 }, 2980 "last-updated": "2015-10-24T18:02:45+02:00" 2981 } 2982 ] 2983 } 2984 }, 2985 { 2986 "name": "ipv6-master", 2987 "address-family": "ietf-ipv6-unicast-routing:ipv6-unicast", 2988 "default-rib": true, 2989 "routes": { 2990 "route": [ 2991 { 2992 "ietf-ipv6-unicast-routing:destination-prefix": 2993 "2001:db8:0:1::/64", 2994 "next-hop": { 2995 "outgoing-interface": "eth0" 2996 }, 2997 "source-protocol": "ietf-routing:direct", 2998 "route-preference": 0, 2999 "last-updated": "2015-10-24T17:11:27+02:00" 3000 }, 3001 { 3002 "ietf-ipv6-unicast-routing:destination-prefix": 3003 "2001:db8:0:2::/64", 3004 "next-hop": { 3005 "outgoing-interface": "eth1" 3006 }, 3007 "source-protocol": "ietf-routing:direct", 3008 "route-preference": 0, 3009 "last-updated": "2015-10-24T17:11:27+02:00" 3010 }, 3011 { 3012 "ietf-ipv6-unicast-routing:destination-prefix": 3013 "::/0", 3014 "next-hop": { 3015 "ietf-ipv6-unicast-routing:next-hop-address": 3016 "2001:db8:0:1::2" 3017 }, 3018 "source-protocol": "ietf-routing:static", 3019 "route-preference": 5, 3020 "last-updated": "2015-10-24T18:02:45+02:00" 3021 } 3022 ] 3023 } 3024 } 3025 ] 3026 } 3027 } 3028 } 3030 Appendix E. Change Log 3032 RFC Editor: Remove this section upon publication as an RFC. 3034 E.1. Changes Between Versions -22 and -23 3036 o Fix paths in "when" expressions due to errata 4749 of RFC 7950. 3038 E.2. Changes Between Versions -22 and -23 3040 o Removed "route-tag" feature. 3042 o Removed next-hop classifiers. 3044 o Fixed invalid when expressions in augments. 3046 o In simple-next-hop, an address, outgoing interface or both can be 3047 specified. 3049 o RPC "fib-route" changed into RIB action "active-route". 3051 o The requirement that direct routes be always placed in default 3052 RIBs. 3054 E.3. Changes Between Versions -21 and -22 3056 o Added "next-hop-list" as a new case of the "next-hop-options" 3057 choice. 3059 o Renamed "routing protocol" to "control plane protocol" in both the 3060 YANG modules and I-D text. 3062 E.4. Changes Between Versions -20 and -21 3064 o Routing instances were removed. 3066 o IPv6 RA parameters were moved to the "ietf-ipv6-router- 3067 advertisements". 3069 E.5. Changes Between Versions -19 and -20 3071 o Assignment of L3 interfaces to routing instances is now part of 3072 interface configuration. 3074 o Next-hop options in configuration were aligned with state data. 3076 o It is recommended to enclose protocol-specific configuration in a 3077 presence container. 3079 E.6. Changes Between Versions -18 and -19 3081 o The leaf "route-preference" was removed from the "routing- 3082 protocol" container in both "routing" and "routing-state". 3084 o The "vrf-routing-instance" identity was added in support of a 3085 common routing-instance type in addition to the "default-routing- 3086 instance". 3088 o Removed "enabled" switch from "routing-protocol". 3090 E.7. Changes Between Versions -17 and -18 3092 o The container "ribs" was moved under "routing-instance" (in both 3093 "routing" and "routing-state"). 3095 o Typedefs "rib-ref" and "rib-state-ref" were removed. 3097 o Removed "recipient-ribs" (both state and configuration). 3099 o Removed "connected-ribs" from "routing-protocol" (both state and 3100 configuration). 3102 o Configuration and state data for IPv6 RA were moved under 3103 "if:interface" and "if:interface-state". 3105 o Assignment of interfaces to routing instances now use leaf-list 3106 rather than list (both config and state). The opposite reference 3107 from "if:interface" to "rt:routing-instance" was changed to a 3108 single leaf (an interface cannot belong to multiple routing 3109 instances). 3111 o Specification of a default RIB is now a simple flag under "rib" 3112 (both config and state). 3114 o Default RIBs are marked by a flag in state data. 3116 E.8. Changes Between Versions -16 and -17 3118 o Added Acee as a co-author. 3120 o Removed all traces of route filters. 3122 o Removed numeric IDs of list entries in state data. 3124 o Removed all next-hop cases except "simple-next-hop" and "special- 3125 next-hop". 3127 o Removed feature "multipath-routes". 3129 o Augmented "ietf-interfaces" module with a leaf-list of leafrefs 3130 pointing form state data of an interface entry to the routing 3131 instance(s) to which the interface is assigned. 3133 E.9. Changes Between Versions -15 and -16 3135 o Added 'type' as the second key component of 'routing-protocol', 3136 both in configuration and state data. 3138 o The restriction of no more than one connected RIB per address 3139 family was removed. 3141 o Removed the 'id' key of routes in RIBs. This list has no keys 3142 anymore. 3144 o Remove the 'id' key from static routes and make 'destination- 3145 prefix' the only key. 3147 o Added 'route-preference' as a new attribute of routes in RIB. 3149 o Added 'active' as a new attribute of routes in RIBs. 3151 o Renamed RPC operation 'active-route' to 'fib-route'. 3153 o Added 'route-preference' as a new parameter of routing protocol 3154 instances, both in configuration and state data. 3156 o Renamed identity 'rt:standard-routing-instance' to 'rt:default- 3157 routing-instance'. 3159 o Added next-hop lists to state data. 3161 o Added two cases for specifying next-hops indirectly - via a new 3162 RIB or a recursive list of next-hops. 3164 o Reorganized next-hop in static routes. 3166 o Removed all 'if-feature' statements from state data. 3168 E.10. Changes Between Versions -14 and -15 3170 o Removed all defaults from state data. 3172 o Removed default from 'cur-hop-limit' in config. 3174 E.11. Changes Between Versions -13 and -14 3176 o Removed dependency of 'connected-ribs' on the 'multiple-ribs' 3177 feature. 3179 o Removed default value of 'cur-hop-limit' in state data. 3181 o Moved parts of descriptions and all references on IPv6 RA 3182 parameters from state data to configuration. 3184 o Added reference to RFC 6536 in the Security section. 3186 E.12. Changes Between Versions -12 and -13 3188 o Wrote appendix about minimum implementation. 3190 o Remove "when" statement for IPv6 router interface state data - it 3191 was dependent on a config value that may not be present. 3193 o Extra container for the next-hop list. 3195 o Names rather than numeric ids are used for referring to list 3196 entries in state data. 3198 o Numeric ids are always declared as mandatory and unique. Their 3199 description states that they are ephemeral. 3201 o Descriptions of "name" keys in state data lists are required to be 3202 persistent. 3204 o 3206 o Removed "if-feature multiple-ribs;" from connected-ribs. 3208 o "rib-name" instead of "name" is used as the name of leafref nodes. 3210 o "next-hop" instead of "nexthop" or "gateway" used throughout, both 3211 in node names and text. 3213 E.13. Changes Between Versions -11 and -12 3215 o Removed feature "advanced-router" and introduced two features 3216 instead: "multiple-ribs" and "multipath-routes". 3218 o Unified the keys of config and state versions of "routing- 3219 instance" and "rib" lists. 3221 o Numerical identifiers of state list entries are not keys anymore, 3222 but they are constrained using the "unique" statement. 3224 o Updated acknowledgements. 3226 E.14. Changes Between Versions -10 and -11 3228 o Migrated address families from IANA enumerations to identities. 3230 o Terminology and node names aligned with the I2RS RIB model: router 3231 -> routing instance, routing table -> RIB. 3233 o Introduced uint64 keys for state lists: routing-instance, rib, 3234 route, nexthop. 3236 o Described the relationship between system-controlled and user- 3237 controlled list entries. 3239 o Feature "user-defined-routing-tables" changed into "advanced- 3240 router". 3242 o Made nexthop into a choice in order to allow for nexthop-list 3243 (I2RS requirement). 3245 o Added nexthop-list with entries having priorities (backup) and 3246 weights (load balancing). 3248 o Updated bibliography references. 3250 E.15. Changes Between Versions -09 and -10 3252 o Added subtree for state data ("/routing-state"). 3254 o Terms "system-controlled entry" and "user-controlled entry" 3255 defined and used. 3257 o New feature "user-defined-routing-tables". Nodes that are useful 3258 only with user-defined routing tables are now conditional. 3260 o Added grouping "router-id". 3262 o In routing tables, "source-protocol" attribute of routes now 3263 reports only protocol type, and its datatype is "identityref". 3265 o Renamed "main-routing-table" to "default-routing-table". 3267 E.16. Changes Between Versions -08 and -09 3269 o Fixed "must" expression for "connected-routing-table". 3271 o Simplified "must" expression for "main-routing-table". 3273 o Moved per-interface configuration of a new routing protocol under 3274 'routing-protocol'. This also affects the 'example-rip' module. 3276 E.17. Changes Between Versions -07 and -08 3278 o Changed reference from RFC6021 to RFC6021bis. 3280 E.18. Changes Between Versions -06 and -07 3282 o The contents of in Appendix D was updated: "eth[01]" 3283 is used as the value of "location", and "forwarding" is on for 3284 both interfaces and both IPv4 and IPv6. 3286 o The "must" expression for "main-routing-table" was modified to 3287 avoid redundant error messages reporting address family mismatch 3288 when "name" points to a non-existent routing table. 3290 o The default behavior for IPv6 RA prefix advertisements was 3291 clarified. 3293 o Changed type of "rt:router-id" to "ip:dotted-quad". 3295 o Type of "rt:router-id" changed to "yang:dotted-quad". 3297 o Fixed missing prefixes in XPath expressions. 3299 E.19. Changes Between Versions -05 and -06 3301 o Document title changed: "Configuration" was replaced by 3302 "Management". 3304 o New typedefs "routing-table-ref" and "route-filter-ref". 3306 o Double slashes "//" were removed from XPath expressions and 3307 replaced with the single "/". 3309 o Removed uniqueness requirement for "router-id". 3311 o Complete data tree is now in Appendix A. 3313 o Changed type of "source-protocol" from "leafref" to "string". 3315 o Clarified the relationship between routing protocol instances and 3316 connected routing tables. 3318 o Added a must constraint saying that a routing table connected to 3319 the direct pseudo-protocol must not be a main routing table. 3321 E.20. Changes Between Versions -04 and -05 3323 o Routing tables are now global, i.e., "routing-tables" is a child 3324 of "routing" rather than "router". 3326 o "must" statement for "static-routes" changed to "when". 3328 o Added "main-routing-tables" containing references to main routing 3329 tables for each address family. 3331 o Removed the defaults for "address-family" and "safi" and made them 3332 mandatory. 3334 o Removed the default for route-filter/type and made this leaf 3335 mandatory. 3337 o If there is no active route for a given destination, the "active- 3338 route" RPC returns no output. 3340 o Added "enabled" switch under "routing-protocol". 3342 o Added "router-type" identity and "type" leaf under "router". 3344 o Route attribute "age" changed to "last-updated", its type is 3345 "yang:date-and-time". 3347 o The "direct" pseudo-protocol is always connected to main routing 3348 tables. 3350 o Entries in the list of connected routing tables renamed from 3351 "routing-table" to "connected-routing-table". 3353 o Added "must" constraint saying that a routing table must not be 3354 its own recipient. 3356 E.21. Changes Between Versions -03 and -04 3358 o Changed "error-tag" for both RPC operations from "missing element" 3359 to "data-missing". 3361 o Removed the decrementing behavior for advertised IPv6 prefix 3362 parameters "valid-lifetime" and "preferred-lifetime". 3364 o Changed the key of the static route lists from "seqno" to "id" 3365 because the routes needn't be sorted. 3367 o Added 'must' constraint saying that "preferred-lifetime" must not 3368 be greater than "valid-lifetime". 3370 E.22. Changes Between Versions -02 and -03 3372 o Module "iana-afn-safi" moved to I-D "iana-if-type". 3374 o Removed forwarding table. 3376 o RPC "get-route" changed to "active-route". Its output is a list 3377 of routes (for multi-path routing). 3379 o New RPC "route-count". 3381 o For both RPCs, specification of negative responses was added. 3383 o Relaxed separation of router instances. 3385 o Assignment of interfaces to router instances needn't be disjoint. 3387 o Route filters are now global. 3389 o Added "allow-all-route-filter" for symmetry. 3391 o Added Section 6 about interactions with "ietf-interfaces" and 3392 "ietf-ip". 3394 o Added "router-id" leaf. 3396 o Specified the names for IPv4/IPv6 unicast main routing tables. 3398 o Route parameter "last-modified" changed to "age". 3400 o Added container "recipient-routing-tables". 3402 E.23. Changes Between Versions -01 and -02 3404 o Added module "ietf-ipv6-unicast-routing". 3406 o The example in Appendix D now uses IP addresses from blocks 3407 reserved for documentation. 3409 o Direct routes appear by default in the forwarding table. 3411 o Network layer interfaces must be assigned to a router instance. 3412 Additional interface configuration may be present. 3414 o The "when" statement is only used with "augment", "must" is used 3415 elsewhere. 3417 o Additional "must" statements were added. 3419 o The "route-content" grouping for IPv4 and IPv6 unicast now 3420 includes the material from the "ietf-routing" version via "uses 3421 rt:route-content". 3423 o Explanation of symbols in the tree representation of data model 3424 hierarchy. 3426 E.24. Changes Between Versions -00 and -01 3428 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 3430 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 3431 safi" module. 3433 o Names of some data nodes were changed, in particular "routing- 3434 process" is now "router". 3436 o The restriction of a single AFN/SAFI per router was lifted. 3438 o RPC operation "delete-route" was removed. 3440 o Illegal XPath references from "get-route" to the datastore were 3441 fixed. 3443 o Section "Security Considerations" was written. 3445 Authors' Addresses 3446 Ladislav Lhotka 3447 CZ.NIC 3449 Email: lhotka@nic.cz 3451 Acee Lindem 3452 Cisco Systems 3454 Email: acee@cisco.com