idnits 2.17.1 draft-ietf-netmod-routing-cfg-23.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 2407 has weird spacing: '...-prefix ine...' == Line 2424 has weird spacing: '...-prefix ine...' == Line 2453 has weird spacing: '...ro type ide...' == Line 2454 has weird spacing: '...ro name str...' == Line 2458 has weird spacing: '...-family ide...' -- The document date (August 18, 2016) is 2805 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: February 19, 2017 Cisco Systems 6 August 18, 2016 8 A YANG Data Model for Routing Management 9 draft-ietf-netmod-routing-cfg-23 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 February 19, 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 -21 and -22 . . . . . . . . . . 65 93 E.3. Changes Between Versions -20 and -21 . . . . . . . . . . 65 94 E.4. Changes Between Versions -19 and -20 . . . . . . . . . . 66 95 E.5. Changes Between Versions -18 and -19 . . . . . . . . . . 66 96 E.6. Changes Between Versions -17 and -18 . . . . . . . . . . 66 97 E.7. Changes Between Versions -16 and -17 . . . . . . . . . . 67 98 E.8. Changes Between Versions -15 and -16 . . . . . . . . . . 67 99 E.9. Changes Between Versions -14 and -15 . . . . . . . . . . 68 100 E.10. Changes Between Versions -13 and -14 . . . . . . . . . . 68 101 E.11. Changes Between Versions -12 and -13 . . . . . . . . . . 68 102 E.12. Changes Between Versions -11 and -12 . . . . . . . . . . 69 103 E.13. Changes Between Versions -10 and -11 . . . . . . . . . . 69 104 E.14. Changes Between Versions -09 and -10 . . . . . . . . . . 69 105 E.15. Changes Between Versions -08 and -09 . . . . . . . . . . 70 106 E.16. Changes Between Versions -07 and -08 . . . . . . . . . . 70 107 E.17. Changes Between Versions -06 and -07 . . . . . . . . . . 70 108 E.18. Changes Between Versions -05 and -06 . . . . . . . . . . 70 109 E.19. Changes Between Versions -04 and -05 . . . . . . . . . . 71 110 E.20. Changes Between Versions -03 and -04 . . . . . . . . . . 72 111 E.21. Changes Between Versions -02 and -03 . . . . . . . . . . 72 112 E.22. Changes Between Versions -01 and -02 . . . . . . . . . . 73 113 E.23. Changes Between Versions -00 and -01 . . . . . . . . . . 73 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 116 1. Introduction 118 This document contains a specification of the following YANG modules: 120 o Module "ietf-routing" provides generic components of a routing 121 data model. 123 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 124 module with additional data specific to IPv4 unicast. 126 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 127 module with additional data specific to IPv6 unicast. Its 128 submodule "ietf-ipv6-router-advertisements" also augments the 129 "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277] modules with 130 IPv6 router configuration variables required by [RFC4861]. 132 These modules together define the so-called core routing data model, 133 which is intended as a basis for future data model development 134 covering more sophisticated routing systems. While these three 135 modules can be directly used for simple IP devices with static 136 routing (see Appendix B), their main purpose is to provide essential 137 building blocks for more complicated data models involving multiple 138 control plane protocols, multicast routing, additional address 139 families, and advanced functions such as route filtering or policy 140 routing. To this end, it is expected that the core routing data 141 model will be augmented by numerous modules developed by other IETF 142 working groups. 144 2. Terminology and Notation 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 The following terms are defined in [RFC6241]: 152 o client, 154 o message, 156 o protocol operation, 158 o server. 160 The following terms are defined in [I-D.ietf-netmod-rfc6020bis]: 162 o action, 164 o augment, 166 o configuration data, 168 o container, 170 o container with presence, 172 o data model, 174 o data node, 176 o feature, 178 o leaf, 180 o list, 182 o mandatory node, 184 o module, 186 o schema tree, 188 o state data, 190 o RPC operation. 192 2.1. Glossary of New Terms 194 core routing data model: YANG data model comprising "ietf-routing", 195 "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing" 196 modules. 198 direct route: a route to a directly connected network. 200 routing information base (RIB): An object containing a list of 201 routes together with other information. See Section 5.2 for 202 details. 204 system-controlled entry: An entry of a list in state data ("config 205 false") that is created by the system independently of what has 206 been explicitly configured. See Section 4.1 for details. 208 user-controlled entry: An entry of a list in state data ("config 209 false") that is created and deleted as a direct consequence of 210 certain configuration changes. See Section 4.1 for details. 212 2.2. Tree Diagrams 214 A simplified graphical representation of the complete data tree is 215 presented in Appendix A, and similar diagrams of its various subtrees 216 appear in the main text. 218 o Brackets "[" and "]" enclose list keys. 220 o Curly braces "{" and "}" contain names of optional features that 221 make the corresponding node conditional. 223 o Abbreviations before data node names: "rw" means configuration 224 (read-write), "ro" state data (read-only), "-x" RPC operations or 225 actions, and "-n" notifications. 227 o Symbols after data node names: "?" means an optional node, "!" a 228 container with presence, and "*" denotes a "list" or "leaf-list". 230 o Parentheses enclose choice and case nodes, and case nodes are also 231 marked with a colon (":"). 233 o Ellipsis ("...") stands for contents of subtrees that are not 234 shown. 236 2.3. Prefixes in Data Node Names 238 In this document, names of data nodes, actions and other data model 239 objects are often used without a prefix, as long as it is clear from 240 the context in which YANG module each name is defined. Otherwise, 241 names are prefixed using the standard prefix associated with the 242 corresponding YANG module, as shown in Table 1. 244 +--------+---------------------------+-----------+ 245 | Prefix | YANG module | Reference | 246 +--------+---------------------------+-----------+ 247 | if | ietf-interfaces | [RFC7223] | 248 | ip | ietf-ip | [RFC7277] | 249 | rt | ietf-routing | Section 7 | 250 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 251 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 252 | yang | ietf-yang-types | [RFC6991] | 253 | inet | ietf-inet-types | [RFC6991] | 254 +--------+---------------------------+-----------+ 256 Table 1: Prefixes and corresponding YANG modules 258 3. Objectives 260 The initial design of the core routing data model was driven by the 261 following objectives: 263 o The data model should be suitable for the common address families, 264 in particular IPv4 and IPv6, and for unicast and multicast 265 routing, as well as Multiprotocol Label Switching (MPLS). 267 o A simple IP routing system, such as one that uses only static 268 routing, should be configurable in a simple way, ideally without 269 any need to develop additional YANG modules. 271 o On the other hand, the core routing framework must allow for 272 complicated implementations involving multiple routing information 273 bases (RIB) and multiple control plane protocols, as well as 274 controlled redistributions of routing information. 276 o Device vendors will want to map the data models built on this 277 generic framework to their proprietary data models and 278 configuration interfaces. Therefore, the framework should be 279 flexible enough to facilitate such a mapping and accommodate data 280 models with different logic. 282 4. The Design of the Core Routing Data Model 284 The core routing data model consists of three YANG modules and one 285 submodule. The first module, "ietf-routing", defines the generic 286 components of a routing system. The other two modules, "ietf-ipv4- 287 unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf- 288 routing" module with additional data nodes that are needed for IPv4 289 and IPv6 unicast routing, respectively. Module "ietf-ipv6-unicast- 290 routing" has a submodule, "ietf-ipv6-router-advertisements", that 291 augments the "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277] 292 modules with configuration variables for IPv6 router advertisements 293 as required by [RFC4861]. Figures 1 and 2 show abridged views of the 294 configuration and state data hierarchies. See Appendix A for the 295 complete data trees. 297 +--rw routing 298 +--rw router-id? 299 +--rw control-plane-protocols 300 | +--rw control-plane-protocol* [type name] 301 | +--rw type 302 | +--rw name 303 | +--rw description? 304 | +--rw static-routes 305 | +--rw v6ur:ipv6 306 | | ... 307 | +--rw v4ur:ipv4 308 | ... 309 +--rw ribs 310 +--rw rib* [name] 311 +--rw name 312 +--rw address-family? 313 +--rw description? 315 Figure 1: Configuration data hierarchy. 317 +--ro routing-state 318 +--ro router-id? 319 +--ro interfaces 320 | +--ro interface* 321 +--ro control-plane-protocols 322 | +--ro control-plane-protocol* [type name] 323 | +--ro type 324 | +--ro name 325 +--ro ribs 326 +--ro rib* [name] 327 +--ro name 328 +--ro address-family 329 +--ro default-rib? 330 +--ro routes 331 | +--ro route* 332 | ... 334 Figure 2: State data hierarchy. 336 As can be seen from Figures 1 and 2, the core routing data model 337 introduces several generic components of a routing framework: routes, 338 RIBs containing lists of routes, and control plane protocols. 339 Section 5 describes these components in more detail. 341 4.1. System-Controlled and User-Controlled List Entries 343 The core routing data model defines several lists in the schema tree, 344 such as "rib", that have to be populated with at least one entry in 345 any properly functioning device, and additional entries may be 346 configured by a client. 348 In such a list, the server creates the required item as a so-called 349 system-controlled entry in state data, i.e., inside the "routing- 350 state" container. 352 An example can be seen in Appendix D: the "/routing-state/ribs/rib" 353 list has two system-controlled entries named "ipv4-master" and 354 "ipv6-master". 356 Additional entries may be created in the configuration by a client, 357 e.g., via the NETCONF protocol. These are so-called user-controlled 358 entries. If the server accepts a configured user-controlled entry, 359 then this entry also appears in the state data version of the list. 361 Corresponding entries in both versions of the list (in state data and 362 configuration) have the same value of the list key. 364 A client may also provide supplemental configuration of system- 365 controlled entries. To do so, the client creates a new entry in the 366 configuration with the desired contents. In order to bind this entry 367 to the corresponding entry in the state data list, the key of the 368 configuration entry has to be set to the same value as the key of the 369 state entry. 371 Deleting a user-controlled entry from the configuration list results 372 in the removal of the corresponding entry in the state data list. In 373 contrast, if a system-controlled entry is deleted from the 374 configuration list, only the extra configuration specified in that 375 entry is removed but the corresponding state data entry remains in 376 the list. 378 5. Basic Building Blocks 380 This section describes the essential components of the core routing 381 data model. 383 5.1. Route 385 Routes are basic elements of information in a routing system. The 386 core routing data model defines only the following minimal set of 387 route attributes: 389 o "destination-prefix": address prefix specifying the set of 390 destination addresses for which the route may be used. This 391 attribute is mandatory. 393 o "route-preference": an integer value (also known as administrative 394 distance) that is used for selecting a preferred route among 395 routes with the same destination prefix. A lower value means a 396 more preferred route. 398 o "next-hop": determines the outgoing interface and/or next-hop 399 address(es), other operation to be performed with a packet. 401 Routes are primarily state data that appear as entries of RIBs 402 (Section 5.2) but they may also be found in configuration data, for 403 example as manually configured static routes. In the latter case, 404 configurable route attributes are generally a subset of attributes 405 defined for RIB routes. 407 5.2. Routing Information Base (RIB) 409 Every implementation of the core routing data model manages one or 410 more routing information bases (RIB). A RIB is a list of routes 411 complemented with administrative data. Each RIB contains only routes 412 of one address family. An address family is represented by an 413 identity derived from the "rt:address-family" base identity. 415 In the core routing data model, RIBs are state data represented as 416 entries of the list "/routing-state/ribs/rib". The contents of RIBs 417 are controlled and manipulated by control plane protocol operations 418 which may result in route additions, removals and modifications. 419 This also includes manipulations via the "static" and/or "direct" 420 pseudo-protocols, see Section 5.3.1. 422 For every supported address family, exactly one RIB MUST be marked as 423 the so-called default RIB. Its role is explained in Section 5.3. 425 Simple router implementations that do not advertise the feature 426 "multiple-ribs" will typically create one system-controlled RIB per 427 supported address family, and mark it as the default RIB. 429 More complex router implementations advertising the "multiple-ribs" 430 feature support multiple RIBs per address family that can be used for 431 policy routing and other purposes. 433 The following action (see Section 7.15 of 434 [I-D.ietf-netmod-rfc6020bis]) is defined for the "rib" list: 436 o active-route -- return the active RIB route for the destination 437 address that is specified as the action's input parameter. 439 5.3. Control Plane Protocol 441 The core routing data model provides an open-ended framework for 442 defining multiple control plane protocol instances, e.g., for Layer 3 443 routing protocols. Each control plane protocol instance MUST be 444 assigned a type, which is an identity derived from the "rt:control- 445 plane-protocol" base identity. The core routing data model defines 446 two identities for the direct and static pseudo-protocols 447 (Section 5.3.1). 449 Multiple control plane protocol instances of the same type MAY be 450 configured. 452 5.3.1. Routing Pseudo-Protocols 454 The core routing data model defines two special routing protocol 455 types -- "direct" and "static". Both are in fact pseudo-protocols, 456 which means that they are confined to the local device and do not 457 exchange any routing information with adjacent routers. 459 Every implementation of the core routing data model MUST provide 460 exactly one instance of the "direct" pseudo-protocol type. It is the 461 source of direct routes for all configured address families. Direct 462 routes are normally supplied by the operating system kernel, based on 463 the configuration of network interface addresses, see Section 6.2. 465 A pseudo-protocol of the type "static" allows for specifying routes 466 manually. It MAY be configured in zero or multiple instances, 467 although a typical configuration will have exactly one instance. 469 5.3.2. Defining New Control Plane Protocols 471 It is expected that future YANG modules will create data models for 472 additional control plane protocol types. Such a new module has to 473 define the protocol-specific configuration and state data, and it has 474 to integrate it into the core routing framework in the following way: 476 o A new identity MUST be defined for the control plane protocol and 477 its base identity MUST be set to "rt:control-plane-protocol", or 478 to an identity derived from "rt:control-plane-protocol". 480 o Additional route attributes MAY be defined, preferably in one 481 place by means of defining a YANG grouping. The new attributes 482 have to be inserted by augmenting the definitions of the nodes 484 /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 486 and 488 /rt:routing-state/rt:ribs/rt:rib/rt:output/rt:route, 490 and possibly other places in the configuration, state data, 491 notifications, and input/output parameters of actions or RPC 492 operations. 494 o Configuration parameters and/or state data for the new protocol 495 can be defined by augmenting the "control-plane-protocol" data 496 node under both "/routing" and "/routing-state". 498 By using a "when" statement, the augmented configuration parameters 499 and state data specific to the new protocol SHOULD be made 500 conditional and valid only if the value of "rt:type" or "rt:source- 501 protocol" is equal to (or derived from) the new protocol's identity. 503 It is also RECOMMENDED that protocol-specific data nodes be 504 encapsulated in an appropriately named container with presence. Such 505 a container may contain mandatory data nodes that are otherwise 506 forbidden at the top level of an augment. 508 The above steps are implemented by the example YANG module for the 509 RIP routing protocol in Appendix C. 511 5.4. Parameters of IPv6 Router Advertisements 513 YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is 514 a submodule of the "ietf-ipv6-unicast-routing" module, augments the 515 configuration and state data of IPv6 interfaces with definitions of 516 the following variables as required by [RFC4861], sec. 6.2.1: 518 o send-advertisements, 520 o max-rtr-adv-interval, 522 o min-rtr-adv-interval, 524 o managed-flag, 526 o other-config-flag, 528 o link-mtu, 530 o reachable-time, 532 o retrans-timer, 534 o cur-hop-limit, 536 o default-lifetime, 538 o prefix-list: a list of prefixes to be advertised. 540 The following parameters are associated with each prefix in the 541 list: 543 * valid-lifetime, 545 * on-link-flag, 547 * preferred-lifetime, 549 * autonomous-flag. 551 NOTES: 553 1. The "IsRouter" flag, which is also required by [RFC4861], is 554 implemented in the "ietf-ip" module [RFC7277] (leaf 555 "ip:forwarding"). 557 2. The original specification [RFC4861] allows the implementations 558 to decide whether the "valid-lifetime" and "preferred-lifetime" 559 parameters remain the same in consecutive advertisements, or 560 decrement in real time. However, the latter behavior seems 561 problematic because the values might be reset again to the 562 (higher) configured values after a configuration is reloaded. 563 Moreover, no implementation is known to use the decrementing 564 behavior. The "ietf-ipv6-router-advertisements" submodule 565 therefore stipulates the former behavior with constant values. 567 6. Interactions with Other YANG Modules 569 The semantics of the core routing data model also depends on several 570 configuration parameters that are defined in other YANG modules. 572 6.1. Module "ietf-interfaces" 574 The following boolean switch is defined in the "ietf-interfaces" YANG 575 module [RFC7223]: 577 /if:interfaces/if:interface/if:enabled 579 If this switch is set to "false" for a network layer interface, 580 then all routing and forwarding functions MUST be disabled on that 581 interface. 583 6.2. Module "ietf-ip" 585 The following boolean switches are defined in the "ietf-ip" YANG 586 module [RFC7277]: 588 /if:interfaces/if:interface/ip:ipv4/ip:enabled 590 If this switch is set to "false" for a network layer interface, 591 then all IPv4 routing and forwarding functions MUST be disabled on 592 that interface. 594 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 596 If this switch is set to "false" for a network layer interface, 597 then the forwarding of IPv4 datagrams through this interface MUST 598 be disabled. However, the interface MAY participate in other IPv4 599 routing functions, such as routing protocols. 601 /if:interfaces/if:interface/ip:ipv6/ip:enabled 602 If this switch is set to "false" for a network layer interface, 603 then all IPv6 routing and forwarding functions MUST be disabled on 604 that interface. 606 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 608 If this switch is set to "false" for a network layer interface, 609 then the forwarding of IPv6 datagrams through this interface MUST 610 be disabled. However, the interface MAY participate in other IPv6 611 routing functions, such as routing protocols. 613 In addition, the "ietf-ip" module allows for configuring IPv4 and 614 IPv6 addresses and network prefixes or masks on network layer 615 interfaces. Configuration of these parameters on an enabled 616 interface MUST result in an immediate creation of the corresponding 617 direct route. The destination prefix of this route is set according 618 to the configured IP address and network prefix/mask, and the 619 interface is set as the outgoing interface for that route. 621 7. Routing Management YANG Module 623 RFC Editor: In this section, replace all occurrences of 'XXXX' with 624 the actual RFC number and all occurrences of the revision date below 625 with the date of RFC publication (and remove this note). 627 file "ietf-routing@2016-08-18.yang" 629 module ietf-routing { 631 yang-version "1.1"; 633 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 635 prefix "rt"; 637 import ietf-yang-types { 638 prefix "yang"; 639 } 641 import ietf-interfaces { 642 prefix "if"; 643 } 645 organization 646 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 648 contact 649 "WG Web: 650 WG List: 652 WG Chair: Lou Berger 653 655 WG Chair: Kent Watsen 656 658 Editor: Ladislav Lhotka 659 661 Editor: Acee Lindem 662 "; 664 description 665 "This YANG module defines essential components for the management 666 of a routing subsystem. 668 Copyright (c) 2016 IETF Trust and the persons identified as 669 authors of the code. All rights reserved. 671 Redistribution and use in source and binary forms, with or 672 without modification, is permitted pursuant to, and subject to 673 the license terms contained in, the Simplified BSD License set 674 forth in Section 4.c of the IETF Trust's Legal Provisions 675 Relating to IETF Documents 676 (http://trustee.ietf.org/license-info). 678 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 679 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 680 'OPTIONAL' in the module text are to be interpreted as described 681 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 683 This version of this YANG module is part of RFC XXXX 684 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 685 full legal notices."; 687 revision 2016-08-18 { 688 description 689 "Initial revision."; 690 reference 691 "RFC XXXX: A YANG Data Model for Routing Management"; 692 } 694 /* Features */ 696 feature multiple-ribs { 697 description 698 "This feature indicates that the server supports user-defined 699 RIBs. 701 Servers that do not advertise this feature SHOULD provide 702 exactly one system-controlled RIB per supported address family 703 and make them also the default RIBs. These RIBs then appear as 704 entries of the list /routing-state/ribs/rib."; 705 } 707 feature router-id { 708 description 709 "This feature indicates that the server supports configuration 710 of an explicit 32-bit router ID that is used by some routing 711 protocols. 713 Servers that do not advertise this feature set a router ID 714 algorithmically, usually to one of configured IPv4 addresses. 715 However, this algorithm is implementation-specific."; 716 } 718 /* Identities */ 720 identity address-family { 721 description 722 "Base identity from which identities describing address 723 families are derived."; 724 } 726 identity ipv4 { 727 base address-family; 728 description 729 "This identity represents IPv4 address family."; 730 } 732 identity ipv6 { 733 base address-family; 734 description 735 "This identity represents IPv6 address family."; 736 } 738 identity control-plane-protocol { 739 description 740 "Base identity from which control plane protocol identities are 741 derived."; 742 } 744 identity routing-protocol { 745 base control-plane-protocol; 746 description 747 "Identity from which Layer 3 routing protocol identities are 748 derived."; 749 } 751 identity direct { 752 base routing-protocol; 753 description 754 "Routing pseudo-protocol that provides routes to directly 755 connected networks."; 756 } 758 identity static { 759 base routing-protocol; 760 description 761 "Static routing pseudo-protocol."; 762 } 764 /* Type Definitions */ 766 typedef route-preference { 767 type uint32; 768 description 769 "This type is used for route preferences."; 770 } 772 /* Groupings */ 774 grouping address-family { 775 description 776 "This grouping provides a leaf identifying an address 777 family."; 778 leaf address-family { 779 type identityref { 780 base address-family; 781 } 782 mandatory "true"; 783 description 784 "Address family."; 785 } 786 } 788 grouping router-id { 789 description 790 "This grouping provides router ID."; 791 leaf router-id { 792 type yang:dotted-quad; 793 description 794 "A 32-bit number in the form of a dotted quad that is used by 795 some routing protocols identifying a router."; 796 reference 797 "RFC 2328: OSPF Version 2."; 798 } 799 } 801 grouping special-next-hop { 802 description 803 "This grouping provides a leaf with an enumeration of special 804 next-hops."; 805 leaf special-next-hop { 806 type enumeration { 807 enum blackhole { 808 description 809 "Silently discard the packet."; 810 } 811 enum unreachable { 812 description 813 "Discard the packet and notify the sender with an error 814 message indicating that the destination host is 815 unreachable."; 816 } 817 enum prohibit { 818 description 819 "Discard the packet and notify the sender with an error 820 message indicating that the communication is 821 administratively prohibited."; 822 } 823 enum receive { 824 description 825 "The packet will be received by the local system."; 826 } 827 } 828 description 829 "Special next-hop options."; 830 } 831 } 833 grouping next-hop-content { 834 description 835 "Generic parameters of next-hops in static routes."; 836 choice next-hop-options { 837 mandatory "true"; 838 description 839 "Options for next-hops in static routes. 841 It is expected that further cases will be added through 842 augments from other modules."; 843 case simple-next-hop { 844 description 845 "This case represents a simple next hop consisting of the 846 next-hop address and/or outgoing interface. 848 Modules for address families MUST augment this case with a 849 leaf containing a next-hop address of that address 850 family."; 851 leaf outgoing-interface { 852 type if:interface-ref; 853 description 854 "Name of the outgoing interface."; 855 } 856 } 857 case special-next-hop { 858 uses special-next-hop; 859 } 860 case next-hop-list { 861 container next-hop-list { 862 description 863 "Container for multiple next-hops."; 864 list next-hop { 865 key "index"; 866 description 867 "An entry of a next-hop list. 869 Modules for address families MUST augment this list 870 with a leaf containing a next-hop address of that 871 address family."; 872 leaf index { 873 type string; 874 description 875 "An user-specified identifier utilised to uniquely 876 reference the next-hop entry in the next-hop list. 877 The value of this index has no semantic meaning 878 other than for referencing the entry."; 879 } 880 leaf outgoing-interface { 881 type if:interface-ref; 882 description 883 "Name of the outgoing interface."; 884 } 885 } 886 } 887 } 888 } 889 } 890 grouping next-hop-state-content { 891 description 892 "Generic parameters of next-hops in state data."; 893 choice next-hop-options { 894 mandatory "true"; 895 description 896 "Options for next-hops in state data. 898 It is expected that further cases will be added through 899 augments from other modules, e.g., for recursive 900 next-hops."; 901 case simple-next-hop { 902 description 903 "This case represents a simple next hop consisting of the 904 next-hop address and/or outgoing interface. 906 Modules for address families MUST augment this case with a 907 leaf containing a next-hop address of that address 908 family."; 909 leaf outgoing-interface { 910 type if:interface-state-ref; 911 description 912 "Name of the outgoing interface."; 913 } 914 } 915 case special-next-hop { 916 uses special-next-hop; 917 } 918 case next-hop-list { 919 container next-hop-list { 920 description 921 "Container for multiple next-hops."; 922 list next-hop { 923 description 924 "An entry of a next-hop list. 926 Modules for address families MUST augment this list 927 with a leaf containing a next-hop address of that 928 address family."; 929 leaf outgoing-interface { 930 type if:interface-state-ref; 931 description 932 "Name of the outgoing interface."; 933 } 934 } 935 } 936 } 937 } 939 } 941 grouping route-metadata { 942 description 943 "Common route metadata."; 944 leaf source-protocol { 945 type identityref { 946 base routing-protocol; 947 } 948 mandatory "true"; 949 description 950 "Type of the routing protocol from which the route 951 originated."; 952 } 953 leaf active { 954 type empty; 955 description 956 "Presence of this leaf indicates that the route is preferred 957 among all routes in the same RIB that have the same 958 destination prefix."; 959 } 960 leaf last-updated { 961 type yang:date-and-time; 962 description 963 "Time stamp of the last modification of the route. If the 964 route was never modified, it is the time when the route was 965 inserted into the RIB."; 966 } 967 } 969 /* State data */ 971 container routing-state { 972 config "false"; 973 description 974 "State data of the routing subsystem."; 975 uses router-id { 976 description 977 "Global router ID. 979 It may be either configured or assigned algorithmically by 980 the implementation."; 981 } 982 container interfaces { 983 description 984 "Network layer interfaces used for routing."; 985 leaf-list interface { 986 type if:interface-state-ref; 987 description 988 "Each entry is a reference to the name of a configured 989 network layer interface."; 990 } 991 } 992 container control-plane-protocols { 993 description 994 "Container for the list of routing protocol instances."; 995 list control-plane-protocol { 996 key "type name"; 997 description 998 "State data of a control plane protocol instance. 1000 An implementation MUST provide exactly one 1001 system-controlled instance of the 'direct' 1002 pseudo-protocol. Instances of other control plane 1003 protocols MAY be created by configuration."; 1004 leaf type { 1005 type identityref { 1006 base control-plane-protocol; 1007 } 1008 description 1009 "Type of the control plane protocol."; 1010 } 1011 leaf name { 1012 type string; 1013 description 1014 "The name of the control plane protocol instance. 1016 For system-controlled instances this name is persistent, 1017 i.e., it SHOULD NOT change across reboots."; 1018 } 1019 } 1020 } 1021 container ribs { 1022 description 1023 "Container for RIBs."; 1024 list rib { 1025 key "name"; 1026 min-elements "1"; 1027 description 1028 "Each entry represents a RIB identified by the 'name' key. 1029 All routes in a RIB MUST belong to the same address 1030 family. 1032 An implementation SHOULD provide one system-controlled 1033 default RIB for each supported address family."; 1034 leaf name { 1035 type string; 1036 description 1037 "The name of the RIB."; 1038 } 1039 uses address-family; 1040 leaf default-rib { 1041 if-feature "multiple-ribs"; 1042 type boolean; 1043 default "true"; 1044 description 1045 "This flag has the value of 'true' if and only if the RIB 1046 is the default RIB for the given address family. 1048 By default, control plane protocols place their routes 1049 in the default RIBs."; 1050 } 1051 container routes { 1052 description 1053 "Current content of the RIB."; 1054 list route { 1055 description 1056 "A RIB route entry. This data node MUST be augmented 1057 with information specific for routes of each address 1058 family."; 1059 leaf route-preference { 1060 type route-preference; 1061 description 1062 "This route attribute, also known as administrative 1063 distance, allows for selecting the preferred route 1064 among routes with the same destination prefix. A 1065 smaller value means a more preferred route."; 1066 } 1067 container next-hop { 1068 description 1069 "Route's next-hop attribute."; 1070 uses next-hop-state-content; 1071 } 1072 uses route-metadata; 1073 } 1074 } 1075 action active-route { 1076 description 1077 "Return the active RIB route that is used for the 1078 destination address. 1080 Address family specific modules MUST augment input 1081 parameters with a leaf named 'destination-address'."; 1082 output { 1083 container route { 1084 description 1085 "The active RIB route for the specified destination. 1087 If no route exists in the RIB for the destination 1088 address, no output is returned. 1090 Address family specific modules MUST augment this 1091 container with appropriate route contents."; 1092 container next-hop { 1093 description 1094 "Route's next-hop attribute."; 1095 uses next-hop-state-content; 1096 } 1097 uses route-metadata; 1098 } 1099 } 1100 } 1101 } 1102 } 1103 } 1105 /* Configuration Data */ 1107 container routing { 1108 description 1109 "Configuration parameters for the routing subsystem."; 1110 uses router-id { 1111 if-feature "router-id"; 1112 description 1113 "Configuration of the global router ID. Routing protocols 1114 that use router ID can use this parameter or override it 1115 with another value."; 1116 } 1117 container control-plane-protocols { 1118 description 1119 "Configuration of control plane protocol instances."; 1120 list control-plane-protocol { 1121 key "type name"; 1122 description 1123 "Each entry contains configuration of a control plane 1124 protocol instance."; 1125 leaf type { 1126 type identityref { 1127 base control-plane-protocol; 1128 } 1129 description 1130 "Type of the control plane protocol - an identity derived 1131 from the 'control-plane-protocol' base identity."; 1132 } 1133 leaf name { 1134 type string; 1135 description 1136 "An arbitrary name of the control plane protocol 1137 instance."; 1138 } 1139 leaf description { 1140 type string; 1141 description 1142 "Textual description of the control plane protocol 1143 instance."; 1144 } 1145 container static-routes { 1146 when "derived-from-or-self(../type, 'rt:static')" { 1147 description 1148 "This container is only valid for the 'static' routing 1149 protocol."; 1150 } 1151 description 1152 "Configuration of the 'static' pseudo-protocol. 1154 Address-family-specific modules augment this node with 1155 their lists of routes."; 1156 } 1157 } 1158 } 1159 container ribs { 1160 description 1161 "Configuration of RIBs."; 1162 list rib { 1163 key "name"; 1164 description 1165 "Each entry contains configuration for a RIB identified by 1166 the 'name' key. 1168 Entries having the same key as a system-controlled entry 1169 of the list /routing-state/ribs/rib are used for 1170 configuring parameters of that entry. Other entries define 1171 additional user-controlled RIBs."; 1172 leaf name { 1173 type string; 1174 description 1175 "The name of the RIB. 1177 For system-controlled entries, the value of this leaf 1178 must be the same as the name of the corresponding entry 1179 in state data. 1181 For user-controlled entries, an arbitrary name can be 1182 used."; 1183 } 1184 uses address-family { 1185 description 1186 "Address family of the RIB. 1188 It is mandatory for user-controlled RIBs. For 1189 system-controlled RIBs it can be omitted, otherwise it 1190 must match the address family of the corresponding state 1191 entry."; 1192 refine "address-family" { 1193 mandatory "false"; 1194 } 1195 } 1196 leaf description { 1197 type string; 1198 description 1199 "Textual description of the RIB."; 1200 } 1201 } 1202 } 1203 } 1204 } 1206 1208 8. IPv4 Unicast Routing Management YANG Module 1210 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1211 the actual RFC number and all occurrences of the revision date below 1212 with the date of RFC publication (and remove this note). 1214 file "ietf-ipv4-unicast-routing@2016-08-18.yang" 1216 module ietf-ipv4-unicast-routing { 1218 yang-version "1.1"; 1220 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1222 prefix "v4ur"; 1224 import ietf-routing { 1225 prefix "rt"; 1226 } 1227 import ietf-inet-types { 1228 prefix "inet"; 1229 } 1231 organization 1232 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1234 contact 1235 "WG Web: 1236 WG List: 1238 WG Chair: Lou Berger 1239 1241 WG Chair: Kent Watsen 1242 1244 Editor: Ladislav Lhotka 1245 1247 Editor: Acee Lindem 1248 "; 1250 description 1251 "This YANG module augments the 'ietf-routing' module with basic 1252 configuration and state data for IPv4 unicast routing. 1254 Copyright (c) 2016 IETF Trust and the persons identified as 1255 authors of the code. All rights reserved. 1257 Redistribution and use in source and binary forms, with or 1258 without modification, is permitted pursuant to, and subject to 1259 the license terms contained in, the Simplified BSD License set 1260 forth in Section 4.c of the IETF Trust's Legal Provisions 1261 Relating to IETF Documents 1262 (http://trustee.ietf.org/license-info). 1264 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1265 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1266 'OPTIONAL' in the module text are to be interpreted as described 1267 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 1269 This version of this YANG module is part of RFC XXXX 1270 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1271 full legal notices."; 1273 revision 2016-08-18 { 1274 description 1275 "Initial revision."; 1276 reference 1277 "RFC XXXX: A YANG Data Model for Routing Management"; 1278 } 1280 /* Identities */ 1282 identity ipv4-unicast { 1283 base rt:ipv4; 1284 description 1285 "This identity represents the IPv4 unicast address family."; 1286 } 1288 /* State data */ 1290 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1291 when "derived-from-or-self(../../rt:address-family, " 1292 + "'v4ur:ipv4-unicast')" { 1293 description 1294 "This augment is valid only for IPv4 unicast."; 1295 } 1296 description 1297 "This leaf augments an IPv4 unicast route."; 1298 leaf destination-prefix { 1299 type inet:ipv4-prefix; 1300 description 1301 "IPv4 destination prefix."; 1302 } 1303 } 1305 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1306 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1307 when "derived-from-or-self(../../../rt:address-family, " 1308 + "'v4ur:ipv4-unicast')" { 1309 description 1310 "This augment is valid only for IPv4 unicast."; 1311 } 1312 description 1313 "Augment 'simple-next-hop' case in IPv4 unicast routes."; 1314 leaf next-hop-address { 1315 type inet:ipv4-address; 1316 description 1317 "IPv4 address of the next-hop."; 1318 } 1319 } 1321 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1322 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1323 + "rt:next-hop-list/rt:next-hop" { 1324 when "derived-from-or-self(../../../../../rt:address-family, " 1325 + "'v4ur:ipv4-unicast')" { 1326 description 1327 "This augment is valid only for IPv4 unicast."; 1328 } 1329 description 1330 "This leaf augments the 'next-hop-list' case of IPv4 unicast 1331 routes."; 1332 leaf address { 1333 type inet:ipv4-address; 1334 description 1335 "IPv4 address of the next-hop."; 1336 } 1337 } 1339 augment 1340 "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" { 1341 when "derived-from-or-self(../../rt:address-family, " 1342 + "'v4ur:ipv4-unicast')" { 1343 description 1344 "This augment is valid only for IPv4 unicast RIBs."; 1345 } 1346 description 1347 "This augment adds the input parameter of the 'active-route' 1348 action."; 1349 leaf destination-address { 1350 type inet:ipv4-address; 1351 description 1352 "IPv4 destination address."; 1353 } 1354 } 1356 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1357 + "rt:output/rt:route" { 1358 when "derived-from-or-self(../../../rt:address-family, " 1359 + "'v4ur:ipv4-unicast')" { 1360 description 1361 "This augment is valid only for IPv4 unicast."; 1362 } 1363 description 1364 "This augment adds the destination prefix to the reply of the 1365 'active-route' action."; 1366 leaf destination-prefix { 1367 type inet:ipv4-prefix; 1368 description 1369 "IPv4 destination prefix."; 1370 } 1372 } 1374 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1375 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1376 + "rt:simple-next-hop" { 1377 when "derived-from-or-self(../../../../rt:address-family, " 1378 + "'v4ur:ipv4-unicast')" { 1379 description 1380 "This augment is valid only for IPv4 unicast."; 1381 } 1382 description 1383 "Augment 'simple-next-hop' case in the reply to the 1384 'active-route' action."; 1385 leaf next-hop-address { 1386 type inet:ipv4-address; 1387 description 1388 "IPv4 address of the next-hop."; 1389 } 1390 } 1392 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1393 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1394 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1395 when "derived-from-or-self(../../../../../../rt:address-family, " 1396 + "'v4ur:ipv4-unicast')" { 1397 description 1398 "This augment is valid only for IPv4 unicast."; 1399 } 1400 description 1401 "Augment 'next-hop-list' case in the reply to the 1402 'active-route' action."; 1403 leaf next-hop-address { 1404 type inet:ipv4-address; 1405 description 1406 "IPv4 address of the next-hop."; 1407 } 1408 } 1410 /* Configuration data */ 1412 augment "/rt:routing/rt:control-plane-protocols/" 1413 + "rt:control-plane-protocol/rt:static-routes" { 1414 description 1415 "This augment defines the configuration of the 'static' 1416 pseudo-protocol with data specific to IPv4 unicast."; 1417 container ipv4 { 1418 description 1419 "Configuration of a 'static' pseudo-protocol instance 1420 consists of a list of routes."; 1421 list route { 1422 key "destination-prefix"; 1423 description 1424 "A list of static routes."; 1425 leaf destination-prefix { 1426 type inet:ipv4-prefix; 1427 mandatory "true"; 1428 description 1429 "IPv4 destination prefix."; 1430 } 1431 leaf description { 1432 type string; 1433 description 1434 "Textual description of the route."; 1435 } 1436 container next-hop { 1437 description 1438 "Configuration of next-hop."; 1439 uses rt:next-hop-content { 1440 augment "next-hop-options/simple-next-hop" { 1441 description 1442 "Augment 'simple-next-hop' case in IPv4 static 1443 routes."; 1444 leaf next-hop-address { 1445 type inet:ipv4-address; 1446 description 1447 "IPv4 address of the next-hop."; 1448 } 1449 } 1450 augment "next-hop-options/next-hop-list/next-hop-list/" 1451 + "next-hop" { 1452 description 1453 "Augment 'next-hop-list' case in IPv4 static 1454 routes."; 1455 leaf next-hop-address { 1456 type inet:ipv4-address; 1457 description 1458 "IPv4 address of the next-hop."; 1459 } 1460 } 1461 } 1462 } 1463 } 1464 } 1465 } 1466 } 1467 1469 9. IPv6 Unicast Routing Management YANG Module 1471 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1472 the actual RFC number and all occurrences of the revision date below 1473 with the date of RFC publication (and remove this note). 1475 file "ietf-ipv6-unicast-routing@2016-08-18.yang" 1477 module ietf-ipv6-unicast-routing { 1479 yang-version "1.1"; 1481 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1483 prefix "v6ur"; 1485 import ietf-routing { 1486 prefix "rt"; 1487 } 1489 import ietf-inet-types { 1490 prefix "inet"; 1491 } 1493 include ietf-ipv6-router-advertisements { 1494 revision-date 2016-08-18; 1495 } 1497 organization 1498 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1500 contact 1501 "WG Web: 1502 WG List: 1504 WG Chair: Lou Berger 1505 1507 WG Chair: Kent Watsen 1508 1510 Editor: Ladislav Lhotka 1511 1513 Editor: Acee Lindem 1514 "; 1516 description 1517 "This YANG module augments the 'ietf-routing' module with basic 1518 configuration and state data for IPv6 unicast routing. 1520 Copyright (c) 2016 IETF Trust and the persons identified as 1521 authors of the code. All rights reserved. 1523 Redistribution and use in source and binary forms, with or 1524 without modification, is permitted pursuant to, and subject to 1525 the license terms contained in, the Simplified BSD License set 1526 forth in Section 4.c of the IETF Trust's Legal Provisions 1527 Relating to IETF Documents 1528 (http://trustee.ietf.org/license-info). 1530 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1531 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1532 'OPTIONAL' in the module text are to be interpreted as described 1533 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 1535 This version of this YANG module is part of RFC XXXX 1536 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1537 full legal notices."; 1539 revision 2016-08-18 { 1540 description 1541 "Initial revision."; 1542 reference 1543 "RFC XXXX: A YANG Data Model for Routing Management"; 1544 } 1546 /* Identities */ 1548 identity ipv6-unicast { 1549 base rt:ipv6; 1550 description 1551 "This identity represents the IPv6 unicast address family."; 1552 } 1554 /* State data */ 1556 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1557 when "derived-from-or-self(../../rt:address-family, " 1558 + "'v6ur:ipv6-unicast')" { 1559 description 1560 "This augment is valid only for IPv6 unicast."; 1561 } 1562 description 1563 "This leaf augments an IPv6 unicast route."; 1565 leaf destination-prefix { 1566 type inet:ipv6-prefix; 1567 description 1568 "IPv6 destination prefix."; 1569 } 1570 } 1572 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1573 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1574 when "derived-from-or-self(../../../rt:address-family, " 1575 + "'v6ur:ipv6-unicast')" { 1576 description 1577 "This augment is valid only for IPv6 unicast."; 1578 } 1579 description 1580 "Augment 'simple-next-hop' case in IPv6 unicast routes."; 1581 leaf next-hop-address { 1582 type inet:ipv6-address; 1583 description 1584 "IPv6 address of the next-hop."; 1585 } 1586 } 1588 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1589 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1590 + "rt:next-hop-list/rt:next-hop" { 1591 when "derived-from-or-self(../../../../../rt:address-family, " 1592 + "'v6ur:ipv6-unicast')" { 1593 description 1594 "This augment is valid only for IPv6 unicast."; 1595 } 1596 description 1597 "This leaf augments the 'next-hop-list' case of IPv6 unicast 1598 routes."; 1599 leaf address { 1600 type inet:ipv6-address; 1601 description 1602 "IPv6 address of the next-hop."; 1603 } 1604 } 1606 augment 1607 "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" { 1608 when "derived-from-or-self(../../rt:address-family, " 1609 + "'v6ur:ipv6-unicast')" { 1610 description 1611 "This augment is valid only for IPv6 unicast RIBs."; 1612 } 1613 description 1614 "This augment adds the input parameter of the 'active-route' 1615 action."; 1616 leaf destination-address { 1617 type inet:ipv6-address; 1618 description 1619 "IPv6 destination address."; 1620 } 1621 } 1623 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1624 + "rt:output/rt:route" { 1625 when "derived-from-or-self(../../../rt:address-family, " 1626 + "'v6ur:ipv6-unicast')" { 1627 description 1628 "This augment is valid only for IPv6 unicast."; 1629 } 1630 description 1631 "This augment adds the destination prefix to the reply of the 1632 'active-route' action."; 1633 leaf destination-prefix { 1634 type inet:ipv6-prefix; 1635 description 1636 "IPv6 destination prefix."; 1637 } 1638 } 1640 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1641 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1642 + "rt:simple-next-hop" { 1643 when "derived-from-or-self(../../../../rt:address-family, " 1644 + "'v6ur:ipv6-unicast')" { 1645 description 1646 "This augment is valid only for IPv6 unicast."; 1647 } 1648 description 1649 "Augment 'simple-next-hop' case in the reply to the 1650 'active-route' action."; 1651 leaf next-hop-address { 1652 type inet:ipv6-address; 1653 description 1654 "IPv6 address of the next-hop."; 1655 } 1656 } 1658 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1659 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1660 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1662 when "derived-from-or-self(../../../../../../rt:address-family, " 1663 + "'v6ur:ipv6-unicast')" { 1664 description 1665 "This augment is valid only for IPv6 unicast."; 1666 } 1667 description 1668 "Augment 'next-hop-list' case in the reply to the 1669 'active-route' action."; 1670 leaf next-hop-address { 1671 type inet:ipv6-address; 1672 description 1673 "IPv6 address of the next-hop."; 1674 } 1675 } 1677 /* Configuration data */ 1679 augment "/rt:routing/rt:control-plane-protocols/" 1680 + "rt:control-plane-protocol/rt:static-routes" { 1681 description 1682 "This augment defines the configuration of the 'static' 1683 pseudo-protocol with data specific to IPv6 unicast."; 1684 container ipv6 { 1685 description 1686 "Configuration of a 'static' pseudo-protocol instance 1687 consists of a list of routes."; 1688 list route { 1689 key "destination-prefix"; 1690 description 1691 "A list of static routes."; 1692 leaf destination-prefix { 1693 type inet:ipv6-prefix; 1694 mandatory "true"; 1695 description 1696 "IPv6 destination prefix."; 1697 } 1698 leaf description { 1699 type string; 1700 description 1701 "Textual description of the route."; 1702 } 1703 container next-hop { 1704 description 1705 "Configuration of next-hop."; 1706 uses rt:next-hop-content { 1707 augment "next-hop-options/simple-next-hop" { 1708 description 1709 "Augment 'simple-next-hop' case in IPv6 static 1710 routes."; 1711 leaf next-hop-address { 1712 type inet:ipv6-address; 1713 description 1714 "IPv6 address of the next-hop."; 1715 } 1716 } 1717 augment "next-hop-options/next-hop-list/next-hop-list/" 1718 + "next-hop" { 1719 description 1720 "Augment 'next-hop-list' case in IPv6 static 1721 routes."; 1722 leaf next-hop-address { 1723 type inet:ipv6-address; 1724 description 1725 "IPv6 address of the next-hop."; 1726 } 1727 } 1728 } 1729 } 1730 } 1731 } 1732 } 1733 } 1735 1737 9.1. IPv6 Router Advertisements Submodule 1739 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1740 the actual RFC number and all occurrences of the revision date below 1741 with the date of RFC publication (and remove this note). 1743 file "ietf-ipv6-router-advertisements@2016-08-18.yang" 1745 submodule ietf-ipv6-router-advertisements { 1747 yang-version "1.1"; 1749 belongs-to ietf-ipv6-unicast-routing { 1750 prefix "v6ur"; 1751 } 1753 import ietf-inet-types { 1754 prefix "inet"; 1755 } 1757 import ietf-interfaces { 1758 prefix "if"; 1759 } 1761 import ietf-ip { 1762 prefix "ip"; 1763 } 1765 organization 1766 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1768 contact 1769 "WG Web: 1770 WG List: 1772 WG Chair: Lou Berger 1773 1775 WG Chair: Kent Watsen 1776 1778 Editor: Ladislav Lhotka 1779 1781 Editor: Acee Lindem 1782 "; 1784 description 1785 "This YANG module augments the 'ietf-ip' module with 1786 configuration and state data of IPv6 router advertisements. 1788 Copyright (c) 2016 IETF Trust and the persons identified as 1789 authors of the code. All rights reserved. 1791 Redistribution and use in source and binary forms, with or 1792 without modification, is permitted pursuant to, and subject to 1793 the license terms contained in, the Simplified BSD License set 1794 forth in Section 4.c of the IETF Trust's Legal Provisions 1795 Relating to IETF Documents 1796 (http://trustee.ietf.org/license-info). 1798 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1799 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1800 'OPTIONAL' in the module text are to be interpreted as described 1801 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 1803 This version of this YANG module is part of RFC XXXX 1804 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1805 full legal notices."; 1807 reference 1808 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)."; 1810 revision 2016-08-18 { 1811 description 1812 "Initial revision."; 1813 reference 1814 "RFC XXXX: A YANG Data Model for Routing Management"; 1815 } 1817 /* State data */ 1819 augment "/if:interfaces-state/if:interface/ip:ipv6" { 1820 description 1821 "Augment interface state data with parameters of IPv6 router 1822 advertisements."; 1823 container ipv6-router-advertisements { 1824 description 1825 "Parameters of IPv6 Router Advertisements."; 1826 leaf send-advertisements { 1827 type boolean; 1828 description 1829 "A flag indicating whether or not the router sends periodic 1830 Router Advertisements and responds to Router 1831 Solicitations."; 1832 } 1833 leaf max-rtr-adv-interval { 1834 type uint16 { 1835 range "4..1800"; 1836 } 1837 units "seconds"; 1838 description 1839 "The maximum time allowed between sending unsolicited 1840 multicast Router Advertisements from the interface."; 1841 } 1842 leaf min-rtr-adv-interval { 1843 type uint16 { 1844 range "3..1350"; 1845 } 1846 units "seconds"; 1847 description 1848 "The minimum time allowed between sending unsolicited 1849 multicast Router Advertisements from the interface."; 1850 } 1851 leaf managed-flag { 1852 type boolean; 1853 description 1854 "The value that is placed in the 'Managed address 1855 configuration' flag field in the Router Advertisement."; 1856 } 1857 leaf other-config-flag { 1858 type boolean; 1859 description 1860 "The value that is placed in the 'Other configuration' flag 1861 field in the Router Advertisement."; 1862 } 1863 leaf link-mtu { 1864 type uint32; 1865 description 1866 "The value that is placed in MTU options sent by the 1867 router. A value of zero indicates that no MTU options are 1868 sent."; 1869 } 1870 leaf reachable-time { 1871 type uint32 { 1872 range "0..3600000"; 1873 } 1874 units "milliseconds"; 1875 description 1876 "The value that is placed in the Reachable Time field in 1877 the Router Advertisement messages sent by the router. A 1878 value of zero means unspecified (by this router)."; 1879 } 1880 leaf retrans-timer { 1881 type uint32; 1882 units "milliseconds"; 1883 description 1884 "The value that is placed in the Retrans Timer field in the 1885 Router Advertisement messages sent by the router. A value 1886 of zero means unspecified (by this router)."; 1887 } 1888 leaf cur-hop-limit { 1889 type uint8; 1890 description 1891 "The value that is placed in the Cur Hop Limit field in the 1892 Router Advertisement messages sent by the router. A value 1893 of zero means unspecified (by this router)."; 1894 } 1895 leaf default-lifetime { 1896 type uint16 { 1897 range "0..9000"; 1898 } 1899 units "seconds"; 1900 description 1901 "The value that is placed in the Router Lifetime field of 1902 Router Advertisements sent from the interface, in seconds. 1904 A value of zero indicates that the router is not to be 1905 used as a default router."; 1906 } 1907 container prefix-list { 1908 description 1909 "A list of prefixes that are placed in Prefix Information 1910 options in Router Advertisement messages sent from the 1911 interface. 1913 By default, these are all prefixes that the router 1914 advertises via routing protocols as being on-link for the 1915 interface from which the advertisement is sent."; 1916 list prefix { 1917 key "prefix-spec"; 1918 description 1919 "Advertised prefix entry and its parameters."; 1920 leaf prefix-spec { 1921 type inet:ipv6-prefix; 1922 description 1923 "IPv6 address prefix."; 1924 } 1925 leaf valid-lifetime { 1926 type uint32; 1927 units "seconds"; 1928 description 1929 "The value that is placed in the Valid Lifetime in the 1930 Prefix Information option. The designated value of all 1931 1's (0xffffffff) represents infinity. 1933 An implementation SHOULD keep this value constant in 1934 consecutive advertisements except when it is 1935 explicitly changed in configuration."; 1936 } 1937 leaf on-link-flag { 1938 type boolean; 1939 description 1940 "The value that is placed in the on-link flag ('L-bit') 1941 field in the Prefix Information option."; 1942 } 1943 leaf preferred-lifetime { 1944 type uint32; 1945 units "seconds"; 1946 description 1947 "The value that is placed in the Preferred Lifetime in 1948 the Prefix Information option, in seconds. The 1949 designated value of all 1's (0xffffffff) represents 1950 infinity. 1952 An implementation SHOULD keep this value constant in 1953 consecutive advertisements except when it is 1954 explicitly changed in configuration."; 1955 } 1956 leaf autonomous-flag { 1957 type boolean; 1958 description 1959 "The value that is placed in the Autonomous Flag field 1960 in the Prefix Information option."; 1961 } 1962 } 1963 } 1964 } 1965 } 1967 /* Configuration data */ 1969 augment "/if:interfaces/if:interface/ip:ipv6" { 1970 description 1971 "Augment interface configuration with parameters of IPv6 router 1972 advertisements."; 1973 container ipv6-router-advertisements { 1974 description 1975 "Configuration of IPv6 Router Advertisements."; 1976 leaf send-advertisements { 1977 type boolean; 1978 default "false"; 1979 description 1980 "A flag indicating whether or not the router sends periodic 1981 Router Advertisements and responds to Router 1982 Solicitations."; 1983 reference 1984 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1985 AdvSendAdvertisements."; 1986 } 1987 leaf max-rtr-adv-interval { 1988 type uint16 { 1989 range "4..1800"; 1990 } 1991 units "seconds"; 1992 default "600"; 1993 description 1994 "The maximum time allowed between sending unsolicited 1995 multicast Router Advertisements from the interface."; 1996 reference 1997 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1998 MaxRtrAdvInterval."; 1999 } 2000 leaf min-rtr-adv-interval { 2001 type uint16 { 2002 range "3..1350"; 2003 } 2004 units "seconds"; 2005 must ". <= 0.75 * ../max-rtr-adv-interval" { 2006 description 2007 "The value MUST NOT be greater than 75 % of 2008 'max-rtr-adv-interval'."; 2009 } 2010 description 2011 "The minimum time allowed between sending unsolicited 2012 multicast Router Advertisements from the interface. 2014 The default value to be used operationally if this leaf is 2015 not configured is determined as follows: 2017 - if max-rtr-adv-interval >= 9 seconds, the default value 2018 is 0.33 * max-rtr-adv-interval; 2020 - otherwise it is 0.75 * max-rtr-adv-interval."; 2021 reference 2022 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2023 MinRtrAdvInterval."; 2024 } 2025 leaf managed-flag { 2026 type boolean; 2027 default "false"; 2028 description 2029 "The value to be placed in the 'Managed address 2030 configuration' flag field in the Router Advertisement."; 2031 reference 2032 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2033 AdvManagedFlag."; 2034 } 2035 leaf other-config-flag { 2036 type boolean; 2037 default "false"; 2038 description 2039 "The value to be placed in the 'Other configuration' flag 2040 field in the Router Advertisement."; 2041 reference 2042 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2043 AdvOtherConfigFlag."; 2044 } 2045 leaf link-mtu { 2046 type uint32; 2047 default "0"; 2048 description 2049 "The value to be placed in MTU options sent by the router. 2050 A value of zero indicates that no MTU options are sent."; 2051 reference 2052 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2053 AdvLinkMTU."; 2054 } 2055 leaf reachable-time { 2056 type uint32 { 2057 range "0..3600000"; 2058 } 2059 units "milliseconds"; 2060 default "0"; 2061 description 2062 "The value to be placed in the Reachable Time field in the 2063 Router Advertisement messages sent by the router. A value 2064 of zero means unspecified (by this router)."; 2065 reference 2066 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2067 AdvReachableTime."; 2068 } 2069 leaf retrans-timer { 2070 type uint32; 2071 units "milliseconds"; 2072 default "0"; 2073 description 2074 "The value to be placed in the Retrans Timer field in the 2075 Router Advertisement messages sent by the router. A value 2076 of zero means unspecified (by this router)."; 2077 reference 2078 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2079 AdvRetransTimer."; 2080 } 2081 leaf cur-hop-limit { 2082 type uint8; 2083 description 2084 "The value to be placed in the Cur Hop Limit field in the 2085 Router Advertisement messages sent by the router. A value 2086 of zero means unspecified (by this router). 2088 If this parameter is not configured, the device SHOULD use 2089 the value specified in IANA Assigned Numbers that was in 2090 effect at the time of implementation."; 2091 reference 2092 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2093 AdvCurHopLimit. 2095 IANA: IP Parameters, 2096 http://www.iana.org/assignments/ip-parameters"; 2097 } 2098 leaf default-lifetime { 2099 type uint16 { 2100 range "0..9000"; 2101 } 2102 units "seconds"; 2103 description 2104 "The value to be placed in the Router Lifetime field of 2105 Router Advertisements sent from the interface, in seconds. 2106 It MUST be either zero or between max-rtr-adv-interval and 2107 9000 seconds. A value of zero indicates that the router is 2108 not to be used as a default router. These limits may be 2109 overridden by specific documents that describe how IPv6 2110 operates over different link layers. 2112 If this parameter is not configured, the device SHOULD use 2113 a value of 3 * max-rtr-adv-interval."; 2114 reference 2115 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2116 AdvDefaultLifeTime."; 2117 } 2118 container prefix-list { 2119 description 2120 "Configuration of prefixes to be placed in Prefix 2121 Information options in Router Advertisement messages sent 2122 from the interface. 2124 Prefixes that are advertised by default but do not have 2125 their entries in the child 'prefix' list are advertised 2126 with the default values of all parameters. 2128 The link-local prefix SHOULD NOT be included in the list 2129 of advertised prefixes."; 2130 reference 2131 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2132 AdvPrefixList."; 2133 list prefix { 2134 key "prefix-spec"; 2135 description 2136 "Configuration of an advertised prefix entry."; 2137 leaf prefix-spec { 2138 type inet:ipv6-prefix; 2139 description 2140 "IPv6 address prefix."; 2141 } 2142 choice control-adv-prefixes { 2143 default "advertise"; 2144 description 2145 "The prefix either may be explicitly removed from the 2146 set of advertised prefixes, or parameters with which 2147 it is advertised may be specified (default case)."; 2148 leaf no-advertise { 2149 type empty; 2150 description 2151 "The prefix will not be advertised. 2153 This can be used for removing the prefix from the 2154 default set of advertised prefixes."; 2155 } 2156 case advertise { 2157 leaf valid-lifetime { 2158 type uint32; 2159 units "seconds"; 2160 default "2592000"; 2161 description 2162 "The value to be placed in the Valid Lifetime in 2163 the Prefix Information option. The designated 2164 value of all 1's (0xffffffff) represents 2165 infinity."; 2166 reference 2167 "RFC 4861: Neighbor Discovery for IP version 6 2168 (IPv6) - AdvValidLifetime."; 2169 } 2170 leaf on-link-flag { 2171 type boolean; 2172 default "true"; 2173 description 2174 "The value to be placed in the on-link flag 2175 ('L-bit') field in the Prefix Information 2176 option."; 2177 reference 2178 "RFC 4861: Neighbor Discovery for IP version 6 2179 (IPv6) - AdvOnLinkFlag."; 2180 } 2181 leaf preferred-lifetime { 2182 type uint32; 2183 units "seconds"; 2184 must ". <= ../valid-lifetime" { 2185 description 2186 "This value MUST NOT be greater than 2187 valid-lifetime."; 2188 } 2189 default "604800"; 2190 description 2191 "The value to be placed in the Preferred Lifetime 2192 in the Prefix Information option. The designated 2193 value of all 1's (0xffffffff) represents 2194 infinity."; 2195 reference 2196 "RFC 4861: Neighbor Discovery for IP version 6 2197 (IPv6) - AdvPreferredLifetime."; 2198 } 2199 leaf autonomous-flag { 2200 type boolean; 2201 default "true"; 2202 description 2203 "The value to be placed in the Autonomous Flag 2204 field in the Prefix Information option."; 2205 reference 2206 "RFC 4861: Neighbor Discovery for IP version 6 2207 (IPv6) - AdvAutonomousFlag."; 2208 } 2209 } 2210 } 2211 } 2212 } 2213 } 2214 } 2215 } 2217 2219 10. IANA Considerations 2221 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2222 actual RFC number (and remove this note). 2224 This document registers the following namespace URIs in the IETF XML 2225 registry [RFC3688]: 2227 -------------------------------------------------------------------- 2228 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2230 Registrant Contact: The IESG. 2232 XML: N/A, the requested URI is an XML namespace. 2233 -------------------------------------------------------------------- 2234 -------------------------------------------------------------------- 2235 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2237 Registrant Contact: The IESG. 2239 XML: N/A, the requested URI is an XML namespace. 2240 -------------------------------------------------------------------- 2242 -------------------------------------------------------------------- 2243 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2245 Registrant Contact: The IESG. 2247 XML: N/A, the requested URI is an XML namespace. 2248 -------------------------------------------------------------------- 2250 This document registers the following YANG modules in the YANG Module 2251 Names registry [RFC6020]: 2253 -------------------------------------------------------------------- 2254 name: ietf-routing 2255 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2256 prefix: rt 2257 reference: RFC XXXX 2258 -------------------------------------------------------------------- 2260 -------------------------------------------------------------------- 2261 name: ietf-ipv4-unicast-routing 2262 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2263 prefix: v4ur 2264 reference: RFC XXXX 2265 -------------------------------------------------------------------- 2267 -------------------------------------------------------------------- 2268 name: ietf-ipv6-unicast-routing 2269 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2270 prefix: v6ur 2271 reference: RFC XXXX 2272 -------------------------------------------------------------------- 2274 This document registers the following YANG submodule in the YANG 2275 Module Names registry [RFC6020]: 2277 -------------------------------------------------------------------- 2278 name: ietf-ipv6-router-advertisements 2279 parent: ietf-ipv6-unicast-routing 2280 reference: RFC XXXX 2281 -------------------------------------------------------------------- 2283 11. Security Considerations 2285 Configuration and state data conforming to the core routing data 2286 model (defined in this document) are designed to be accessed via a 2287 management protocol with secure transport layer, such as NETCONF 2288 [RFC6241]. The NETCONF access control model [RFC6536] provides the 2289 means to restrict access for particular NETCONF users to a pre- 2290 configured subset of all available NETCONF protocol operations and 2291 content. 2293 A number of configuration data nodes defined in the YANG modules 2294 belonging to the core routing data model are writable/creatable/ 2295 deletable (i.e., "config true" in YANG terms, which is the default). 2296 These data nodes may be considered sensitive or vulnerable in some 2297 network environments. Write operations to these data nodes, such as 2298 "edit-config" in NETCONF, can have negative effects on the network if 2299 the protocol operations are not properly protected. 2301 The vulnerable "config true" parameters and subtrees are the 2302 following: 2304 /routing/control-plane-protocols/control-plane-protocol: This list 2305 specifies the control plane protocols configured on a device. 2307 /routing/ribs/rib: This list specifies the RIBs configured for the 2308 device. 2310 Unauthorised access to any of these lists can adversely affect the 2311 routing subsystem of both the local device and the network. This may 2312 lead to network malfunctions, delivery of packets to inappropriate 2313 destinations and other problems. 2315 12. Acknowledgments 2317 The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean 2318 Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini, 2319 David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane 2320 Litkowski, Thomas Morin, Tom Petch, Yingzhen Qu, Bruno Rijsman, 2321 Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man- 2322 Kit Yeung and Jeffrey Zhang for their helpful comments and 2323 suggestions. 2325 13. References 2326 13.1. Normative References 2328 [I-D.ietf-netmod-rfc6020bis] 2329 Bjorklund, M., "The YANG 1.1 Data Modeling Language", 2330 draft-ietf-netmod-rfc6020bis-14 (work in progress), June 2331 2016. 2333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2334 Requirement Levels", BCP 14, RFC 2119, 2335 DOI 10.17487/RFC2119, March 1997, 2336 . 2338 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2339 DOI 10.17487/RFC3688, January 2004, 2340 . 2342 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2343 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2344 DOI 10.17487/RFC4861, September 2007, 2345 . 2347 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2348 the Network Configuration Protocol (NETCONF)", RFC 6020, 2349 DOI 10.17487/RFC6020, October 2010, 2350 . 2352 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2353 and A. Bierman, Ed., "Network Configuration Protocol 2354 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2355 . 2357 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2358 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2359 . 2361 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2362 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2363 . 2365 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 2366 RFC 7277, DOI 10.17487/RFC7277, June 2014, 2367 . 2369 13.2. Informative References 2371 [I-D.ietf-netmod-yang-json] 2372 Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2373 draft-ietf-netmod-yang-json-10 (work in progress), March 2374 2016. 2376 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2377 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 2378 January 2011, . 2380 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2381 Protocol (NETCONF) Access Control Model", RFC 6536, 2382 DOI 10.17487/RFC6536, March 2012, 2383 . 2385 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 2386 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 2387 . 2389 Appendix A. The Complete Data Trees 2391 This appendix presents the complete configuration and state data 2392 trees of the core routing data model. See Section 2.2 for an 2393 explanation of the symbols used. Data type of every leaf node is 2394 shown near the right end of the corresponding line. 2396 A.1. Configuration Data 2397 +--rw routing 2398 +--rw router-id? yang:dotted-quad 2399 +--rw control-plane-protocols 2400 | +--rw control-plane-protocol* [type name] 2401 | +--rw type identityref 2402 | +--rw name string 2403 | +--rw description? string 2404 | +--rw static-routes 2405 | +--rw v6ur:ipv6 2406 | | +--rw v6ur:route* [destination-prefix] 2407 | | +--rw v6ur:destination-prefix inet:ipv6-prefix 2408 | | +--rw v6ur:description? string 2409 | | +--rw v6ur:next-hop 2410 | | +--rw (v6ur:next-hop-options) 2411 | | +--:(v6ur:simple-next-hop) 2412 | | | +--rw v6ur:outgoing-interface? 2413 | | | +--rw v6ur:next-hop-address? 2414 | | +--:(v6ur:special-next-hop) 2415 | | | +--rw v6ur:special-next-hop? enumeration 2416 | | +--:(v6ur:next-hop-list) 2417 | | +--rw v6ur:next-hop-list 2418 | | +--rw v6ur:next-hop* [index] 2419 | | +--rw v6ur:index string 2420 | | +--rw v6ur:outgoing-interface? 2421 | | +--rw v6ur:next-hop-address? 2422 | +--rw v4ur:ipv4 2423 | +--rw v4ur:route* [destination-prefix] 2424 | +--rw v4ur:destination-prefix inet:ipv4-prefix 2425 | +--rw v4ur:description? string 2426 | +--rw v4ur:next-hop 2427 | +--rw (v4ur:next-hop-options) 2428 | +--:(v4ur:simple-next-hop) 2429 | | +--rw v4ur:outgoing-interface? 2430 | | +--rw v4ur:next-hop-address? 2431 | +--:(v4ur:special-next-hop) 2432 | | +--rw v4ur:special-next-hop? enumeration 2433 | +--:(v4ur:next-hop-list) 2434 | +--rw v4ur:next-hop-list 2435 | +--rw v4ur:next-hop* [index] 2436 | +--rw v4ur:index string 2437 | +--rw v4ur:outgoing-interface? 2438 | +--rw v4ur:next-hop-address? 2439 +--rw ribs 2440 +--rw rib* [name] 2441 +--rw name string 2442 +--rw address-family? identityref 2443 +--rw description? string 2445 A.2. State Data 2447 +--ro routing-state 2448 | +--ro router-id? yang:dotted-quad 2449 | +--ro interfaces 2450 | | +--ro interface* if:interface-state-ref 2451 | +--ro control-plane-protocols 2452 | | +--ro control-plane-protocol* [type name] 2453 | | +--ro type identityref 2454 | | +--ro name string 2455 | +--ro ribs 2456 | +--ro rib* [name] 2457 | +--ro name string 2458 | +--ro address-family identityref 2459 | +--ro default-rib? boolean {multiple-ribs}? 2460 | +--ro routes 2461 | | +--ro route* 2462 | | +--ro route-preference? route-preference 2463 | | +--ro next-hop 2464 | | | +--ro (next-hop-options) 2465 | | | +--:(simple-next-hop) 2466 | | | | +--ro outgoing-interface? 2467 | | | | +--ro v6ur:next-hop-address? 2468 | | | | +--ro v4ur:next-hop-address? 2469 | | | +--:(special-next-hop) 2470 | | | | +--ro special-next-hop? enumeration 2471 | | | +--:(next-hop-list) 2472 | | | +--ro next-hop-list 2473 | | | +--ro next-hop* 2474 | | | +--ro outgoing-interface? 2475 | | | +--ro v6ur:address? 2476 | | | +--ro v4ur:address? 2477 | | +--ro source-protocol identityref 2478 | | +--ro active? empty 2479 | | +--ro last-updated? yang:date-and-time 2480 | | +--ro v6ur:destination-prefix? inet:ipv6-prefix 2481 | | +--ro v4ur:destination-prefix? inet:ipv4-prefix 2482 | +---x active-route 2483 | +---w input 2484 | | +---w v6ur:destination-address? inet:ipv6-address 2485 | | +---w v4ur:destination-address? inet:ipv4-address 2486 | +--ro output 2487 | +--ro route 2488 | +--ro next-hop 2489 | | +--ro (next-hop-options) 2490 | | +--:(simple-next-hop) 2491 | | | +--ro outgoing-interface? 2492 | | | +--ro v6ur:next-hop-address? 2493 | | | +--ro v4ur:next-hop-address? 2494 | | +--:(special-next-hop) 2495 | | | +--ro special-next-hop? enumeration 2496 | | +--:(next-hop-list) 2497 | | +--ro next-hop-list 2498 | | +--ro next-hop* 2499 | | +--ro outgoing-interface? 2500 | | +--ro v6ur:next-hop-address? 2501 | | +--ro v4ur:next-hop-address? 2502 | +--ro source-protocol identityref 2503 | +--ro active? empty 2504 | +--ro last-updated? yang:date-and-time 2505 | +--ro v6ur:destination-prefix? inet:ipv6-prefix 2506 | +--ro v4ur:destination-prefix? inet:ipv4-prefix 2508 Appendix B. Minimum Implementation 2510 Some parts and options of the core routing model, such as user- 2511 defined RIBs, are intended only for advanced routers. This appendix 2512 gives basic non-normative guidelines for implementing a bare minimum 2513 of available functions. Such an implementation may be used for hosts 2514 or very simple routers. 2516 A minimum implementation does not support the feature "multiple- 2517 ribs". This means that a single system-controlled RIB is available 2518 for each supported address family - IPv4, IPv6 or both. These RIBs 2519 are also the default RIBs. No user-controlled RIBs are allowed. 2521 In addition to the mandatory instance of the "direct" pseudo- 2522 protocol, a minimum implementation should support configuring 2523 instance(s) of the "static" pseudo-protocol. 2525 Platforms with severely constrained resources may use deviations for 2526 restricting the data model, e.g., limiting the number of "static" 2527 control plane protocol instances. 2529 Appendix C. Example: Adding a New Control Plane Protocol 2531 This appendix demonstrates how the core routing data model can be 2532 extended to support a new control plane protocol. The YANG module 2533 "example-rip" shown below is intended as an illustration rather than 2534 a real definition of a data model for the RIP routing protocol. For 2535 the sake of brevity, this module does not obey all the guidelines 2536 specified in [RFC6087]. See also Section 5.3.2. 2538 module example-rip { 2540 yang-version "1.1"; 2541 namespace "http://example.com/rip"; 2543 prefix "rip"; 2545 import ietf-interfaces { 2546 prefix "if"; 2547 } 2549 import ietf-routing { 2550 prefix "rt"; 2551 } 2553 identity rip { 2554 base rt:routing-protocol; 2555 description 2556 "Identity for the RIP routing protocol."; 2557 } 2559 typedef rip-metric { 2560 type uint8 { 2561 range "0..16"; 2562 } 2563 } 2565 grouping route-content { 2566 description 2567 "This grouping defines RIP-specific route attributes."; 2568 leaf metric { 2569 type rip-metric; 2570 } 2571 leaf tag { 2572 type uint16; 2573 default "0"; 2574 description 2575 "This leaf may be used to carry additional info, e.g. AS 2576 number."; 2577 } 2578 } 2580 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 2581 when "derived-from-or-self(rt:source-protocol, 'rip:rip')" { 2582 description 2583 "This augment is only valid for a routes whose source 2584 protocol is RIP."; 2585 } 2586 description 2587 "RIP-specific route attributes."; 2588 uses route-content; 2590 } 2592 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 2593 + "rt:output/rt:route" { 2594 description 2595 "RIP-specific route attributes in the output of 'active-route' 2596 RPC."; 2597 uses route-content; 2598 } 2600 augment "/rt:routing/rt:control-plane-protocols/" 2601 + "rt:control-plane-protocol" { 2602 when "derived-from-or-self(rt:type,'rip:rip')" { 2603 description 2604 "This augment is only valid for a routing protocol instance 2605 of type 'rip'."; 2606 } 2607 container rip { 2608 presence "RIP configuration"; 2609 description 2610 "RIP instance configuration."; 2611 container interfaces { 2612 description 2613 "Per-interface RIP configuration."; 2614 list interface { 2615 key "name"; 2616 description 2617 "RIP is enabled on interfaces that have an entry in this 2618 list, unless 'enabled' is set to 'false' for that 2619 entry."; 2620 leaf name { 2621 type if:interface-ref; 2622 } 2623 leaf enabled { 2624 type boolean; 2625 default "true"; 2626 } 2627 leaf metric { 2628 type rip-metric; 2629 default "1"; 2630 } 2631 } 2632 } 2633 leaf update-interval { 2634 type uint8 { 2635 range "10..60"; 2636 } 2637 units "seconds"; 2638 default "30"; 2639 description 2640 "Time interval between periodic updates."; 2641 } 2642 } 2643 } 2644 } 2646 Appendix D. Data Tree Example 2648 This section contains an example instance data tree in the JSON 2649 encoding [I-D.ietf-netmod-yang-json], containing both configuration 2650 and state data. The data conforms to a data model that is defined by 2651 the following YANG library specification [RFC7895]: 2653 { 2654 "ietf-yang-library:modules-state": { 2655 "module-set-id": "3e9be92f252db56fe912cd61a6f516ecf2f46315", 2656 "module": [ 2657 { 2658 "name": "ietf-routing", 2659 "revision": "2016-08-18", 2660 "feature": [ 2661 "multiple-ribs", 2662 "router-id" 2663 ], 2664 "namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", 2665 "conformance-type": "implement" 2666 }, 2667 { 2668 "name": "ietf-ipv4-unicast-routing", 2669 "revision": "2016-08-18", 2670 "namespace": 2671 "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing", 2672 "conformance-type": "implement" 2673 }, 2674 { 2675 "name": "ietf-ipv6-unicast-routing", 2676 "revision": "2016-08-18", 2677 "namespace": 2678 "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing", 2679 "conformance-type": "implement", 2680 "submodule": [ 2681 { 2682 "name": "ietf-ipv6-router-advertisements", 2683 "revision": "2016-08-18" 2684 } 2685 ] 2687 }, 2688 { 2689 "name": "ietf-interfaces", 2690 "revision": "2014-05-08", 2691 "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", 2692 "conformance-type": "implement" 2693 }, 2694 { 2695 "name": "iana-if-type", 2696 "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type", 2697 "revision": "", 2698 "conformance-type": "implement" 2699 }, 2700 { 2701 "name": "ietf-inet-types", 2702 "revision": "2013-07-15", 2703 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 2704 "conformance-type": "import" 2705 }, 2706 { 2707 "name": "ietf-yang-types", 2708 "revision": "2013-07-15", 2709 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2710 "conformance-type": "import" 2711 }, 2712 { 2713 "name": "ietf-ip", 2714 "revision": "2014-06-16", 2715 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", 2716 "conformance-type": "implement" 2717 } 2718 ] 2719 } 2720 } 2722 A simple network set-up as shown in Figure 3 is assumed: router "A" 2723 uses static default routes with the "ISP" router as the next-hop. 2724 IPv6 router advertisements are configured only on the "eth1" 2725 interface and disabled on the upstream "eth0" interface. 2727 +-----------------+ 2728 | | 2729 | Router ISP | 2730 | | 2731 +--------+--------+ 2732 |2001:db8:0:1::2 2733 |192.0.2.2 2734 | 2735 | 2736 |2001:db8:0:1::1 2737 eth0|192.0.2.1 2738 +--------+--------+ 2739 | | 2740 | Router A | 2741 | | 2742 +--------+--------+ 2743 eth1|198.51.100.1 2744 |2001:db8:0:2::1 2745 | 2747 Figure 3: Example network configuration 2749 The instance data tree could then be as follows: 2751 { 2752 "ietf-interfaces:interfaces": { 2753 "interface": [ 2754 { 2755 "name": "eth0", 2756 "type": "iana-if-type:ethernetCsmacd", 2757 "description": "Uplink to ISP.", 2758 "ietf-ip:ipv4": { 2759 "address": [ 2760 { 2761 "ip": "192.0.2.1", 2762 "prefix-length": 24 2763 } 2764 ], 2765 "forwarding": true 2766 }, 2767 "ietf-ip:ipv6": { 2768 "address": [ 2769 { 2770 "ip": "2001:0db8:0:1::1", 2771 "prefix-length": 64 2772 } 2773 ], 2774 "forwarding": true, 2775 "autoconf": { 2776 "create-global-addresses": false 2777 } 2778 } 2779 }, 2780 { 2781 "name": "eth1", 2782 "type": "iana-if-type:ethernetCsmacd", 2783 "description": "Interface to the internal network.", 2784 "ietf-ip:ipv4": { 2785 "address": [ 2786 { 2787 "ip": "198.51.100.1", 2788 "prefix-length": 24 2789 } 2790 ], 2791 "forwarding": true 2792 }, 2793 "ietf-ip:ipv6": { 2794 "address": [ 2795 { 2796 "ip": "2001:0db8:0:2::1", 2797 "prefix-length": 64 2798 } 2799 ], 2800 "forwarding": true, 2801 "autoconf": { 2802 "create-global-addresses": false 2803 }, 2804 "ietf-ipv6-unicast-routing:ipv6-router-advertisements": { 2805 "send-advertisements": true 2806 } 2807 } 2808 } 2809 ] 2810 }, 2811 "ietf-interfaces:interfaces-state": { 2812 "interface": [ 2813 { 2814 "name": "eth0", 2815 "type": "iana-if-type:ethernetCsmacd", 2816 "phys-address": "00:0C:42:E5:B1:E9", 2817 "oper-status": "up", 2818 "statistics": { 2819 "discontinuity-time": "2015-10-24T17:11:27+02:00" 2820 }, 2821 "ietf-ip:ipv4": { 2822 "forwarding": true, 2823 "mtu": 1500, 2824 "address": [ 2825 { 2826 "ip": "192.0.2.1", 2827 "prefix-length": 24 2828 } 2829 ] 2830 }, 2831 "ietf-ip:ipv6": { 2832 "forwarding": true, 2833 "mtu": 1500, 2834 "address": [ 2835 { 2836 "ip": "2001:0db8:0:1::1", 2837 "prefix-length": 64 2838 } 2839 ], 2840 "ietf-ipv6-unicast-routing:ipv6-router-advertisements": { 2841 "send-advertisements": true, 2842 "prefix-list": { 2843 "prefix": [ 2844 { 2845 "prefix-spec": "2001:db8:0:2::/64" 2846 } 2847 ] 2848 } 2849 } 2850 } 2851 }, 2852 { 2853 "name": "eth1", 2854 "type": "iana-if-type:ethernetCsmacd", 2855 "phys-address": "00:0C:42:E5:B1:EA", 2856 "oper-status": "up", 2857 "statistics": { 2858 "discontinuity-time": "2015-10-24T17:11:29+02:00" 2859 }, 2860 "ietf-ip:ipv4": { 2861 "forwarding": true, 2862 "mtu": 1500, 2863 "address": [ 2864 { 2865 "ip": "198.51.100.1", 2866 "prefix-length": 24 2867 } 2868 ] 2869 }, 2870 "ietf-ip:ipv6": { 2871 "forwarding": true, 2872 "mtu": 1500, 2873 "address": [ 2874 { 2875 "ip": "2001:0db8:0:2::1", 2876 "prefix-length": 64 2877 } 2878 ], 2879 "ietf-ipv6-unicast-routing:ipv6-router-advertisements": { 2880 "send-advertisements": true, 2881 "prefix-list": { 2882 "prefix": [ 2883 { 2884 "prefix-spec": "2001:db8:0:2::/64" 2885 } 2886 ] 2887 } 2888 } 2889 } 2890 } 2891 ] 2892 }, 2893 "ietf-routing:routing": { 2894 "router-id": "192.0.2.1", 2895 "control-plane-protocols": { 2896 "control-plane-protocol": [ 2897 { 2898 "type": "ietf-routing:static", 2899 "name": "st0", 2900 "description": 2901 "Static routing is used for the internal network.", 2902 "static-routes": { 2903 "ietf-ipv4-unicast-routing:ipv4": { 2904 "route": [ 2905 { 2906 "destination-prefix": "0.0.0.0/0", 2907 "next-hop": { 2908 "next-hop-address": "192.0.2.2" 2909 } 2910 } 2911 ] 2912 }, 2913 "ietf-ipv6-unicast-routing:ipv6": { 2914 "route": [ 2915 { 2916 "destination-prefix": "::/0", 2917 "next-hop": { 2918 "next-hop-address": "2001:db8:0:1::2" 2920 } 2921 } 2922 ] 2923 } 2924 } 2925 } 2926 ] 2927 } 2928 }, 2929 "ietf-routing:routing-state": { 2930 "interfaces": { 2931 "interface": [ 2932 "eth0", 2933 "eth1" 2934 ] 2935 }, 2936 "control-plane-protocols": { 2937 "control-plane-protocol": [ 2938 { 2939 "type": "ietf-routing:static", 2940 "name": "st0" 2941 } 2942 ] 2943 }, 2944 "ribs": { 2945 "rib": [ 2946 { 2947 "name": "ipv4-master", 2948 "address-family": "ietf-ipv4-unicast-routing:ipv4-unicast", 2949 "default-rib": true, 2950 "routes": { 2951 "route": [ 2952 { 2953 "ietf-ipv4-unicast-routing:destination-prefix": 2954 "192.0.2.1/24", 2955 "next-hop": { 2956 "outgoing-interface": "eth0" 2957 }, 2958 "route-preference": 0, 2959 "source-protocol": "ietf-routing:direct", 2960 "last-updated": "2015-10-24T17:11:27+02:00" 2961 }, 2962 { 2963 "ietf-ipv4-unicast-routing:destination-prefix": 2964 "198.51.100.0/24", 2965 "next-hop": { 2966 "outgoing-interface": "eth1" 2967 }, 2968 "source-protocol": "ietf-routing:direct", 2969 "route-preference": 0, 2970 "last-updated": "2015-10-24T17:11:27+02:00" 2971 }, 2972 { 2973 "ietf-ipv4-unicast-routing:destination-prefix": 2974 "0.0.0.0/0", 2975 "source-protocol": "ietf-routing:static", 2976 "route-preference": 5, 2977 "next-hop": { 2978 "ietf-ipv4-unicast-routing:next-hop-address": 2979 "192.0.2.2" 2980 }, 2981 "last-updated": "2015-10-24T18:02:45+02:00" 2982 } 2983 ] 2984 } 2985 }, 2986 { 2987 "name": "ipv6-master", 2988 "address-family": "ietf-ipv6-unicast-routing:ipv6-unicast", 2989 "default-rib": true, 2990 "routes": { 2991 "route": [ 2992 { 2993 "ietf-ipv6-unicast-routing:destination-prefix": 2994 "2001:db8:0:1::/64", 2995 "next-hop": { 2996 "outgoing-interface": "eth0" 2997 }, 2998 "source-protocol": "ietf-routing:direct", 2999 "route-preference": 0, 3000 "last-updated": "2015-10-24T17:11:27+02:00" 3001 }, 3002 { 3003 "ietf-ipv6-unicast-routing:destination-prefix": 3004 "2001:db8:0:2::/64", 3005 "next-hop": { 3006 "outgoing-interface": "eth1" 3007 }, 3008 "source-protocol": "ietf-routing:direct", 3009 "route-preference": 0, 3010 "last-updated": "2015-10-24T17:11:27+02:00" 3011 }, 3012 { 3013 "ietf-ipv6-unicast-routing:destination-prefix": 3014 "::/0", 3015 "next-hop": { 3016 "ietf-ipv6-unicast-routing:next-hop-address": 3017 "2001:db8:0:1::2" 3018 }, 3019 "source-protocol": "ietf-routing:static", 3020 "route-preference": 5, 3021 "last-updated": "2015-10-24T18:02:45+02:00" 3022 } 3023 ] 3024 } 3025 } 3026 ] 3027 } 3028 } 3029 } 3031 Appendix E. Change Log 3033 RFC Editor: Remove this section upon publication as an RFC. 3035 E.1. Changes Between Versions -22 and -23 3037 o Removed "route-tag" feature. 3039 o Removed next-hop classifiers. 3041 o Fixed invalid when expressions in augments. 3043 o In simple-next-hop, an address, outgoing interface or both can be 3044 specified. 3046 o RPC "fib-route" changed into RIB action "active-route". 3048 o The requirement that direct routes be always placed in default 3049 RIBs. 3051 E.2. Changes Between Versions -21 and -22 3053 o Added "next-hop-list" as a new case of the "next-hop-options" 3054 choice. 3056 o Renamed "routing protocol" to "control plane protocol" in both the 3057 YANG modules and I-D text. 3059 E.3. Changes Between Versions -20 and -21 3061 o Routing instances were removed. 3063 o IPv6 RA parameters were moved to the "ietf-ipv6-router- 3064 advertisements". 3066 E.4. Changes Between Versions -19 and -20 3068 o Assignment of L3 interfaces to routing instances is now part of 3069 interface configuration. 3071 o Next-hop options in configuration were aligned with state data. 3073 o It is recommended to enclose protocol-specific configuration in a 3074 presence container. 3076 E.5. Changes Between Versions -18 and -19 3078 o The leaf "route-preference" was removed from the "routing- 3079 protocol" container in both "routing" and "routing-state". 3081 o The "vrf-routing-instance" identity was added in support of a 3082 common routing-instance type in addition to the "default-routing- 3083 instance". 3085 o Removed "enabled" switch from "routing-protocol". 3087 E.6. Changes Between Versions -17 and -18 3089 o The container "ribs" was moved under "routing-instance" (in both 3090 "routing" and "routing-state"). 3092 o Typedefs "rib-ref" and "rib-state-ref" were removed. 3094 o Removed "recipient-ribs" (both state and configuration). 3096 o Removed "connected-ribs" from "routing-protocol" (both state and 3097 configuration). 3099 o Configuration and state data for IPv6 RA were moved under 3100 "if:interface" and "if:interface-state". 3102 o Assignment of interfaces to routing instances now use leaf-list 3103 rather than list (both config and state). The opposite reference 3104 from "if:interface" to "rt:routing-instance" was changed to a 3105 single leaf (an interface cannot belong to multiple routing 3106 instances). 3108 o Specification of a default RIB is now a simple flag under "rib" 3109 (both config and state). 3111 o Default RIBs are marked by a flag in state data. 3113 E.7. Changes Between Versions -16 and -17 3115 o Added Acee as a co-author. 3117 o Removed all traces of route filters. 3119 o Removed numeric IDs of list entries in state data. 3121 o Removed all next-hop cases except "simple-next-hop" and "special- 3122 next-hop". 3124 o Removed feature "multipath-routes". 3126 o Augmented "ietf-interfaces" module with a leaf-list of leafrefs 3127 pointing form state data of an interface entry to the routing 3128 instance(s) to which the interface is assigned. 3130 E.8. Changes Between Versions -15 and -16 3132 o Added 'type' as the second key component of 'routing-protocol', 3133 both in configuration and state data. 3135 o The restriction of no more than one connected RIB per address 3136 family was removed. 3138 o Removed the 'id' key of routes in RIBs. This list has no keys 3139 anymore. 3141 o Remove the 'id' key from static routes and make 'destination- 3142 prefix' the only key. 3144 o Added 'route-preference' as a new attribute of routes in RIB. 3146 o Added 'active' as a new attribute of routes in RIBs. 3148 o Renamed RPC operation 'active-route' to 'fib-route'. 3150 o Added 'route-preference' as a new parameter of routing protocol 3151 instances, both in configuration and state data. 3153 o Renamed identity 'rt:standard-routing-instance' to 'rt:default- 3154 routing-instance'. 3156 o Added next-hop lists to state data. 3158 o Added two cases for specifying next-hops indirectly - via a new 3159 RIB or a recursive list of next-hops. 3161 o Reorganized next-hop in static routes. 3163 o Removed all 'if-feature' statements from state data. 3165 E.9. Changes Between Versions -14 and -15 3167 o Removed all defaults from state data. 3169 o Removed default from 'cur-hop-limit' in config. 3171 E.10. Changes Between Versions -13 and -14 3173 o Removed dependency of 'connected-ribs' on the 'multiple-ribs' 3174 feature. 3176 o Removed default value of 'cur-hop-limit' in state data. 3178 o Moved parts of descriptions and all references on IPv6 RA 3179 parameters from state data to configuration. 3181 o Added reference to RFC 6536 in the Security section. 3183 E.11. Changes Between Versions -12 and -13 3185 o Wrote appendix about minimum implementation. 3187 o Remove "when" statement for IPv6 router interface state data - it 3188 was dependent on a config value that may not be present. 3190 o Extra container for the next-hop list. 3192 o Names rather than numeric ids are used for referring to list 3193 entries in state data. 3195 o Numeric ids are always declared as mandatory and unique. Their 3196 description states that they are ephemeral. 3198 o Descriptions of "name" keys in state data lists are required to be 3199 persistent. 3201 o 3203 o Removed "if-feature multiple-ribs;" from connected-ribs. 3205 o "rib-name" instead of "name" is used as the name of leafref nodes. 3207 o "next-hop" instead of "nexthop" or "gateway" used throughout, both 3208 in node names and text. 3210 E.12. Changes Between Versions -11 and -12 3212 o Removed feature "advanced-router" and introduced two features 3213 instead: "multiple-ribs" and "multipath-routes". 3215 o Unified the keys of config and state versions of "routing- 3216 instance" and "rib" lists. 3218 o Numerical identifiers of state list entries are not keys anymore, 3219 but they are constrained using the "unique" statement. 3221 o Updated acknowledgements. 3223 E.13. Changes Between Versions -10 and -11 3225 o Migrated address families from IANA enumerations to identities. 3227 o Terminology and node names aligned with the I2RS RIB model: router 3228 -> routing instance, routing table -> RIB. 3230 o Introduced uint64 keys for state lists: routing-instance, rib, 3231 route, nexthop. 3233 o Described the relationship between system-controlled and user- 3234 controlled list entries. 3236 o Feature "user-defined-routing-tables" changed into "advanced- 3237 router". 3239 o Made nexthop into a choice in order to allow for nexthop-list 3240 (I2RS requirement). 3242 o Added nexthop-list with entries having priorities (backup) and 3243 weights (load balancing). 3245 o Updated bibliography references. 3247 E.14. Changes Between Versions -09 and -10 3249 o Added subtree for state data ("/routing-state"). 3251 o Terms "system-controlled entry" and "user-controlled entry" 3252 defined and used. 3254 o New feature "user-defined-routing-tables". Nodes that are useful 3255 only with user-defined routing tables are now conditional. 3257 o Added grouping "router-id". 3259 o In routing tables, "source-protocol" attribute of routes now 3260 reports only protocol type, and its datatype is "identityref". 3262 o Renamed "main-routing-table" to "default-routing-table". 3264 E.15. Changes Between Versions -08 and -09 3266 o Fixed "must" expression for "connected-routing-table". 3268 o Simplified "must" expression for "main-routing-table". 3270 o Moved per-interface configuration of a new routing protocol under 3271 'routing-protocol'. This also affects the 'example-rip' module. 3273 E.16. Changes Between Versions -07 and -08 3275 o Changed reference from RFC6021 to RFC6021bis. 3277 E.17. Changes Between Versions -06 and -07 3279 o The contents of in Appendix D was updated: "eth[01]" 3280 is used as the value of "location", and "forwarding" is on for 3281 both interfaces and both IPv4 and IPv6. 3283 o The "must" expression for "main-routing-table" was modified to 3284 avoid redundant error messages reporting address family mismatch 3285 when "name" points to a non-existent routing table. 3287 o The default behavior for IPv6 RA prefix advertisements was 3288 clarified. 3290 o Changed type of "rt:router-id" to "ip:dotted-quad". 3292 o Type of "rt:router-id" changed to "yang:dotted-quad". 3294 o Fixed missing prefixes in XPath expressions. 3296 E.18. Changes Between Versions -05 and -06 3298 o Document title changed: "Configuration" was replaced by 3299 "Management". 3301 o New typedefs "routing-table-ref" and "route-filter-ref". 3303 o Double slashes "//" were removed from XPath expressions and 3304 replaced with the single "/". 3306 o Removed uniqueness requirement for "router-id". 3308 o Complete data tree is now in Appendix A. 3310 o Changed type of "source-protocol" from "leafref" to "string". 3312 o Clarified the relationship between routing protocol instances and 3313 connected routing tables. 3315 o Added a must constraint saying that a routing table connected to 3316 the direct pseudo-protocol must not be a main routing table. 3318 E.19. Changes Between Versions -04 and -05 3320 o Routing tables are now global, i.e., "routing-tables" is a child 3321 of "routing" rather than "router". 3323 o "must" statement for "static-routes" changed to "when". 3325 o Added "main-routing-tables" containing references to main routing 3326 tables for each address family. 3328 o Removed the defaults for "address-family" and "safi" and made them 3329 mandatory. 3331 o Removed the default for route-filter/type and made this leaf 3332 mandatory. 3334 o If there is no active route for a given destination, the "active- 3335 route" RPC returns no output. 3337 o Added "enabled" switch under "routing-protocol". 3339 o Added "router-type" identity and "type" leaf under "router". 3341 o Route attribute "age" changed to "last-updated", its type is 3342 "yang:date-and-time". 3344 o The "direct" pseudo-protocol is always connected to main routing 3345 tables. 3347 o Entries in the list of connected routing tables renamed from 3348 "routing-table" to "connected-routing-table". 3350 o Added "must" constraint saying that a routing table must not be 3351 its own recipient. 3353 E.20. Changes Between Versions -03 and -04 3355 o Changed "error-tag" for both RPC operations from "missing element" 3356 to "data-missing". 3358 o Removed the decrementing behavior for advertised IPv6 prefix 3359 parameters "valid-lifetime" and "preferred-lifetime". 3361 o Changed the key of the static route lists from "seqno" to "id" 3362 because the routes needn't be sorted. 3364 o Added 'must' constraint saying that "preferred-lifetime" must not 3365 be greater than "valid-lifetime". 3367 E.21. Changes Between Versions -02 and -03 3369 o Module "iana-afn-safi" moved to I-D "iana-if-type". 3371 o Removed forwarding table. 3373 o RPC "get-route" changed to "active-route". Its output is a list 3374 of routes (for multi-path routing). 3376 o New RPC "route-count". 3378 o For both RPCs, specification of negative responses was added. 3380 o Relaxed separation of router instances. 3382 o Assignment of interfaces to router instances needn't be disjoint. 3384 o Route filters are now global. 3386 o Added "allow-all-route-filter" for symmetry. 3388 o Added Section 6 about interactions with "ietf-interfaces" and 3389 "ietf-ip". 3391 o Added "router-id" leaf. 3393 o Specified the names for IPv4/IPv6 unicast main routing tables. 3395 o Route parameter "last-modified" changed to "age". 3397 o Added container "recipient-routing-tables". 3399 E.22. Changes Between Versions -01 and -02 3401 o Added module "ietf-ipv6-unicast-routing". 3403 o The example in Appendix D now uses IP addresses from blocks 3404 reserved for documentation. 3406 o Direct routes appear by default in the forwarding table. 3408 o Network layer interfaces must be assigned to a router instance. 3409 Additional interface configuration may be present. 3411 o The "when" statement is only used with "augment", "must" is used 3412 elsewhere. 3414 o Additional "must" statements were added. 3416 o The "route-content" grouping for IPv4 and IPv6 unicast now 3417 includes the material from the "ietf-routing" version via "uses 3418 rt:route-content". 3420 o Explanation of symbols in the tree representation of data model 3421 hierarchy. 3423 E.23. Changes Between Versions -00 and -01 3425 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 3427 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 3428 safi" module. 3430 o Names of some data nodes were changed, in particular "routing- 3431 process" is now "router". 3433 o The restriction of a single AFN/SAFI per router was lifted. 3435 o RPC operation "delete-route" was removed. 3437 o Illegal XPath references from "get-route" to the datastore were 3438 fixed. 3440 o Section "Security Considerations" was written. 3442 Authors' Addresses 3443 Ladislav Lhotka 3444 CZ.NIC 3446 Email: lhotka@nic.cz 3448 Acee Lindem 3449 Cisco Systems 3451 Email: acee@cisco.com