idnits 2.17.00 (12 Aug 2021) /tmp/idnits50646/draft-ietf-netmod-routing-cfg-25.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 (November 03, 2016) is 2018 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: May 7, 2017 Cisco Systems 6 November 03, 2016 8 A YANG Data Model for Routing Management 9 draft-ietf-netmod-routing-cfg-25 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 May 7, 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 -24 and -25 . . . . . . . . . . 65 92 E.2. Changes Between Versions -23 and -24 . . . . . . . . . . 65 93 E.3. Changes Between Versions -22 and -23 . . . . . . . . . . 65 94 E.4. Changes Between Versions -21 and -22 . . . . . . . . . . 66 95 E.5. Changes Between Versions -20 and -21 . . . . . . . . . . 66 96 E.6. Changes Between Versions -19 and -20 . . . . . . . . . . 66 97 E.7. Changes Between Versions -18 and -19 . . . . . . . . . . 66 98 E.8. Changes Between Versions -17 and -18 . . . . . . . . . . 66 99 E.9. Changes Between Versions -16 and -17 . . . . . . . . . . 67 100 E.10. Changes Between Versions -15 and -16 . . . . . . . . . . 67 101 E.11. Changes Between Versions -14 and -15 . . . . . . . . . . 68 102 E.12. Changes Between Versions -13 and -14 . . . . . . . . . . 68 103 E.13. Changes Between Versions -12 and -13 . . . . . . . . . . 68 104 E.14. Changes Between Versions -11 and -12 . . . . . . . . . . 69 105 E.15. Changes Between Versions -10 and -11 . . . . . . . . . . 69 106 E.16. Changes Between Versions -09 and -10 . . . . . . . . . . 70 107 E.17. Changes Between Versions -08 and -09 . . . . . . . . . . 70 108 E.18. Changes Between Versions -07 and -08 . . . . . . . . . . 70 109 E.19. Changes Between Versions -06 and -07 . . . . . . . . . . 70 110 E.20. Changes Between Versions -05 and -06 . . . . . . . . . . 71 111 E.21. Changes Between Versions -04 and -05 . . . . . . . . . . 71 112 E.22. Changes Between Versions -03 and -04 . . . . . . . . . . 72 113 E.23. Changes Between Versions -02 and -03 . . . . . . . . . . 72 114 E.24. Changes Between Versions -01 and -02 . . . . . . . . . . 73 115 E.25. Changes Between Versions -00 and -01 . . . . . . . . . . 73 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 118 1. Introduction 120 This document contains a specification of the following YANG modules: 122 o Module "ietf-routing" provides generic components of a routing 123 data model. 125 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 126 module with additional data specific to IPv4 unicast. 128 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 129 module with additional data specific to IPv6 unicast. Its 130 submodule "ietf-ipv6-router-advertisements" also augments the 131 "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277] modules with 132 IPv6 router configuration variables required by [RFC4861]. 134 These modules together define the so-called core routing data model, 135 which is intended as a basis for future data model development 136 covering more sophisticated routing systems. While these three 137 modules can be directly used for simple IP devices with static 138 routing (see Appendix B), their main purpose is to provide essential 139 building blocks for more complicated data models involving multiple 140 control plane protocols, multicast routing, additional address 141 families, and advanced functions such as route filtering or policy 142 routing. To this end, it is expected that the core routing data 143 model will be augmented by numerous modules developed by other IETF 144 working groups. 146 2. Terminology and Notation 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 The following terms are defined in [RFC6241]: 154 o client, 156 o message, 158 o protocol operation, 160 o server. 162 The following terms are defined in [RFC7950]: 164 o action, 166 o augment, 168 o configuration data, 170 o container, 172 o container with presence, 174 o data model, 176 o data node, 178 o feature, 180 o leaf, 182 o list, 184 o mandatory node, 186 o module, 188 o schema tree, 190 o state data, 192 o RPC operation. 194 2.1. Glossary of New Terms 196 core routing data model: YANG data model comprising "ietf-routing", 197 "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing" 198 modules. 200 direct route: a route to a directly connected network. 202 routing information base (RIB): An object containing a list of 203 routes together with other information. See Section 5.2 for 204 details. 206 system-controlled entry: An entry of a list in state data ("config 207 false") that is created by the system independently of what has 208 been explicitly configured. See Section 4.1 for details. 210 user-controlled entry: An entry of a list in state data ("config 211 false") that is created and deleted as a direct consequence of 212 certain configuration changes. See Section 4.1 for details. 214 2.2. Tree Diagrams 216 A simplified graphical representation of the complete data tree is 217 presented in Appendix A, and similar diagrams of its various subtrees 218 appear in the main text. 220 o Brackets "[" and "]" enclose list keys. 222 o Curly braces "{" and "}" contain names of optional features that 223 make the corresponding node conditional. 225 o Abbreviations before data node names: "rw" means configuration 226 (read-write), "ro" state data (read-only), "-x" RPC operations or 227 actions, and "-n" notifications. 229 o Symbols after data node names: "?" means an optional node, "!" a 230 container with presence, and "*" denotes a "list" or "leaf-list". 232 o Parentheses enclose choice and case nodes, and case nodes are also 233 marked with a colon (":"). 235 o Ellipsis ("...") stands for contents of subtrees that are not 236 shown. 238 2.3. Prefixes in Data Node Names 240 In this document, names of data nodes, actions and other data model 241 objects are often used without a prefix, as long as it is clear from 242 the context in which YANG module each name is defined. Otherwise, 243 names are prefixed using the standard prefix associated with the 244 corresponding YANG module, as shown in Table 1. 246 +--------+---------------------------+-----------+ 247 | Prefix | YANG module | Reference | 248 +--------+---------------------------+-----------+ 249 | if | ietf-interfaces | [RFC7223] | 250 | ip | ietf-ip | [RFC7277] | 251 | rt | ietf-routing | Section 7 | 252 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 253 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 254 | yang | ietf-yang-types | [RFC6991] | 255 | inet | ietf-inet-types | [RFC6991] | 256 +--------+---------------------------+-----------+ 258 Table 1: Prefixes and corresponding YANG modules 260 3. Objectives 262 The initial design of the core routing data model was driven by the 263 following objectives: 265 o The data model should be suitable for the common address families, 266 in particular IPv4 and IPv6, and for unicast and multicast 267 routing, as well as Multiprotocol Label Switching (MPLS). 269 o A simple IP routing system, such as one that uses only static 270 routing, should be configurable in a simple way, ideally without 271 any need to develop additional YANG modules. 273 o On the other hand, the core routing framework must allow for 274 complicated implementations involving multiple routing information 275 bases (RIB) and multiple control plane protocols, as well as 276 controlled redistributions of routing information. 278 o Device vendors will want to map the data models built on this 279 generic framework to their proprietary data models and 280 configuration interfaces. Therefore, the framework should be 281 flexible enough to facilitate such a mapping and accommodate data 282 models with different logic. 284 4. The Design of the Core Routing Data Model 286 The core routing data model consists of three YANG modules and one 287 submodule. The first module, "ietf-routing", defines the generic 288 components of a routing system. The other two modules, "ietf-ipv4- 289 unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf- 290 routing" module with additional data nodes that are needed for IPv4 291 and IPv6 unicast routing, respectively. Module "ietf-ipv6-unicast- 292 routing" has a submodule, "ietf-ipv6-router-advertisements", that 293 augments the "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277] 294 modules with configuration variables for IPv6 router advertisements 295 as required by [RFC4861]. Figures 1 and 2 show abridged views of the 296 configuration and state data hierarchies. See Appendix A for the 297 complete data trees. 299 +--rw routing 300 +--rw router-id? 301 +--rw control-plane-protocols 302 | +--rw control-plane-protocol* [type name] 303 | +--rw type 304 | +--rw name 305 | +--rw description? 306 | +--rw static-routes 307 | +--rw v6ur:ipv6 308 | | ... 309 | +--rw v4ur:ipv4 310 | ... 311 +--rw ribs 312 +--rw rib* [name] 313 +--rw name 314 +--rw address-family? 315 +--rw description? 317 Figure 1: Configuration data hierarchy. 319 +--ro routing-state 320 +--ro router-id? 321 +--ro interfaces 322 | +--ro interface* 323 +--ro control-plane-protocols 324 | +--ro control-plane-protocol* [type name] 325 | +--ro type 326 | +--ro name 327 +--ro ribs 328 +--ro rib* [name] 329 +--ro name 330 +--ro address-family 331 +--ro default-rib? 332 +--ro routes 333 | +--ro route* 334 | ... 336 Figure 2: State data hierarchy. 338 As can be seen from Figures 1 and 2, the core routing data model 339 introduces several generic components of a routing framework: routes, 340 RIBs containing lists of routes, and control plane protocols. 341 Section 5 describes these components in more detail. 343 4.1. System-Controlled and User-Controlled List Entries 345 The core routing data model defines several lists in the schema tree, 346 such as "rib", that have to be populated with at least one entry in 347 any properly functioning device, and additional entries may be 348 configured by a client. 350 In such a list, the server creates the required item as a so-called 351 system-controlled entry in state data, i.e., inside the "routing- 352 state" container. 354 An example can be seen in Appendix D: the "/routing-state/ribs/rib" 355 list has two system-controlled entries named "ipv4-master" and 356 "ipv6-master". 358 Additional entries may be created in the configuration by a client, 359 e.g., via the NETCONF protocol. These are so-called user-controlled 360 entries. If the server accepts a configured user-controlled entry, 361 then this entry also appears in the state data version of the list. 363 Corresponding entries in both versions of the list (in state data and 364 configuration) have the same value of the list key. 366 A client may also provide supplemental configuration of system- 367 controlled entries. To do so, the client creates a new entry in the 368 configuration with the desired contents. In order to bind this entry 369 to the corresponding entry in the state data list, the key of the 370 configuration entry has to be set to the same value as the key of the 371 state entry. 373 Deleting a user-controlled entry from the configuration list results 374 in the removal of the corresponding entry in the state data list. In 375 contrast, if a system-controlled entry is deleted from the 376 configuration list, only the extra configuration specified in that 377 entry is removed but the corresponding state data entry remains in 378 the list. 380 5. Basic Building Blocks 382 This section describes the essential components of the core routing 383 data model. 385 5.1. Route 387 Routes are basic elements of information in a routing system. The 388 core routing data model defines only the following minimal set of 389 route attributes: 391 o "destination-prefix": address prefix specifying the set of 392 destination addresses for which the route may be used. This 393 attribute is mandatory. 395 o "route-preference": an integer value (also known as administrative 396 distance) that is used for selecting a preferred route among 397 routes with the same destination prefix. A lower value means a 398 more preferred route. 400 o "next-hop": determines the outgoing interface and/or next-hop 401 address(es), other operation to be performed with a packet. 403 Routes are primarily state data that appear as entries of RIBs 404 (Section 5.2) but they may also be found in configuration data, for 405 example as manually configured static routes. In the latter case, 406 configurable route attributes are generally a subset of attributes 407 defined for RIB routes. 409 5.2. Routing Information Base (RIB) 411 Every implementation of the core routing data model manages one or 412 more routing information bases (RIB). A RIB is a list of routes 413 complemented with administrative data. Each RIB contains only routes 414 of one address family. An address family is represented by an 415 identity derived from the "rt:address-family" base identity. 417 In the core routing data model, RIBs are state data represented as 418 entries of the list "/routing-state/ribs/rib". The contents of RIBs 419 are controlled and manipulated by control plane protocol operations 420 which may result in route additions, removals and modifications. 421 This also includes manipulations via the "static" and/or "direct" 422 pseudo-protocols, see Section 5.3.1. 424 For every supported address family, exactly one RIB MUST be marked as 425 the so-called default RIB. Its role is explained in Section 5.3. 427 Simple router implementations that do not advertise the feature 428 "multiple-ribs" will typically create one system-controlled RIB per 429 supported address family, and mark it as the default RIB. 431 More complex router implementations advertising the "multiple-ribs" 432 feature support multiple RIBs per address family that can be used for 433 policy routing and other purposes. 435 The following action (see Section 7.15 of [RFC7950]) is defined for 436 the "rib" list: 438 o active-route -- return the active RIB route for the destination 439 address that is specified as the action's input parameter. 441 5.3. Control Plane Protocol 443 The core routing data model provides an open-ended framework for 444 defining multiple control plane protocol instances, e.g., for Layer 3 445 routing protocols. Each control plane protocol instance MUST be 446 assigned a type, which is an identity derived from the "rt:control- 447 plane-protocol" base identity. The core routing data model defines 448 two identities for the direct and static pseudo-protocols 449 (Section 5.3.1). 451 Multiple control plane protocol instances of the same type MAY be 452 configured. 454 5.3.1. Routing Pseudo-Protocols 456 The core routing data model defines two special routing protocol 457 types -- "direct" and "static". Both are in fact pseudo-protocols, 458 which means that they are confined to the local device and do not 459 exchange any routing information with adjacent routers. 461 Every implementation of the core routing data model MUST provide 462 exactly one instance of the "direct" pseudo-protocol type. It is the 463 source of direct routes for all configured address families. Direct 464 routes are normally supplied by the operating system kernel, based on 465 the configuration of network interface addresses, see Section 6.2. 467 A pseudo-protocol of the type "static" allows for specifying routes 468 manually. It MAY be configured in zero or multiple instances, 469 although a typical configuration will have exactly one instance. 471 5.3.2. Defining New Control Plane Protocols 473 It is expected that future YANG modules will create data models for 474 additional control plane protocol types. Such a new module has to 475 define the protocol-specific configuration and state data, and it has 476 to integrate it into the core routing framework in the following way: 478 o A new identity MUST be defined for the control plane protocol and 479 its base identity MUST be set to "rt:control-plane-protocol", or 480 to an identity derived from "rt:control-plane-protocol". 482 o Additional route attributes MAY be defined, preferably in one 483 place by means of defining a YANG grouping. The new attributes 484 have to be inserted by augmenting the definitions of the nodes 486 /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 488 and 490 /rt:routing-state/rt:ribs/rt:rib/rt:output/rt:route, 492 and possibly other places in the configuration, state data, 493 notifications, and input/output parameters of actions or RPC 494 operations. 496 o Configuration parameters and/or state data for the new protocol 497 can be defined by augmenting the "control-plane-protocol" data 498 node under both "/routing" and "/routing-state". 500 By using a "when" statement, the augmented configuration parameters 501 and state data specific to the new protocol SHOULD be made 502 conditional and valid only if the value of "rt:type" or "rt:source- 503 protocol" is equal to (or derived from) the new protocol's identity. 505 It is also RECOMMENDED that protocol-specific data nodes be 506 encapsulated in an appropriately named container with presence. Such 507 a container may contain mandatory data nodes that are otherwise 508 forbidden at the top level of an augment. 510 The above steps are implemented by the example YANG module for the 511 RIP routing protocol in Appendix C. 513 5.4. Parameters of IPv6 Router Advertisements 515 YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is 516 a submodule of the "ietf-ipv6-unicast-routing" module, augments the 517 configuration and state data of IPv6 interfaces with definitions of 518 the following variables as required by [RFC4861], sec. 6.2.1: 520 o send-advertisements, 522 o max-rtr-adv-interval, 524 o min-rtr-adv-interval, 526 o managed-flag, 528 o other-config-flag, 530 o link-mtu, 532 o reachable-time, 534 o retrans-timer, 536 o cur-hop-limit, 538 o default-lifetime, 540 o prefix-list: a list of prefixes to be advertised. 542 The following parameters are associated with each prefix in the 543 list: 545 * valid-lifetime, 547 * on-link-flag, 549 * preferred-lifetime, 551 * autonomous-flag. 553 NOTES: 555 1. The "IsRouter" flag, which is also required by [RFC4861], is 556 implemented in the "ietf-ip" module [RFC7277] (leaf 557 "ip:forwarding"). 559 2. The original specification [RFC4861] allows the implementations 560 to decide whether the "valid-lifetime" and "preferred-lifetime" 561 parameters remain the same in consecutive advertisements, or 562 decrement in real time. However, the latter behavior seems 563 problematic because the values might be reset again to the 564 (higher) configured values after a configuration is reloaded. 565 Moreover, no implementation is known to use the decrementing 566 behavior. The "ietf-ipv6-router-advertisements" submodule 567 therefore stipulates the former behavior with constant values. 569 6. Interactions with Other YANG Modules 571 The semantics of the core routing data model also depends on several 572 configuration parameters that are defined in other YANG modules. 574 6.1. Module "ietf-interfaces" 576 The following boolean switch is defined in the "ietf-interfaces" YANG 577 module [RFC7223]: 579 /if:interfaces/if:interface/if:enabled 581 If this switch is set to "false" for a network layer interface, 582 then all routing and forwarding functions MUST be disabled on that 583 interface. 585 6.2. Module "ietf-ip" 587 The following boolean switches are defined in the "ietf-ip" YANG 588 module [RFC7277]: 590 /if:interfaces/if:interface/ip:ipv4/ip:enabled 592 If this switch is set to "false" for a network layer interface, 593 then all IPv4 routing and forwarding functions MUST be disabled on 594 that interface. 596 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 598 If this switch is set to "false" for a network layer interface, 599 then the forwarding of IPv4 datagrams through this interface MUST 600 be disabled. However, the interface MAY participate in other IPv4 601 routing functions, such as routing protocols. 603 /if:interfaces/if:interface/ip:ipv6/ip:enabled 604 If this switch is set to "false" for a network layer interface, 605 then all IPv6 routing and forwarding functions MUST be disabled on 606 that interface. 608 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 610 If this switch is set to "false" for a network layer interface, 611 then the forwarding of IPv6 datagrams through this interface MUST 612 be disabled. However, the interface MAY participate in other IPv6 613 routing functions, such as routing protocols. 615 In addition, the "ietf-ip" module allows for configuring IPv4 and 616 IPv6 addresses and network prefixes or masks on network layer 617 interfaces. Configuration of these parameters on an enabled 618 interface MUST result in an immediate creation of the corresponding 619 direct route. The destination prefix of this route is set according 620 to the configured IP address and network prefix/mask, and the 621 interface is set as the outgoing interface for that route. 623 7. Routing Management YANG Module 625 RFC Editor: In this section, replace all occurrences of 'XXXX' with 626 the actual RFC number and all occurrences of the revision date below 627 with the date of RFC publication (and remove this note). 629 file "ietf-routing@2016-11-03.yang" 631 module ietf-routing { 633 yang-version "1.1"; 635 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 637 prefix "rt"; 639 import ietf-yang-types { 640 prefix "yang"; 641 } 643 import ietf-interfaces { 644 prefix "if"; 645 } 647 organization 648 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 650 contact 651 "WG Web: 652 WG List: 654 WG Chair: Lou Berger 655 657 WG Chair: Kent Watsen 658 660 Editor: Ladislav Lhotka 661 663 Editor: Acee Lindem 664 "; 666 description 667 "This YANG module defines essential components for the management 668 of a routing subsystem. 670 Copyright (c) 2016 IETF Trust and the persons identified as 671 authors of the code. All rights reserved. 673 Redistribution and use in source and binary forms, with or 674 without modification, is permitted pursuant to, and subject to 675 the license terms contained in, the Simplified BSD License set 676 forth in Section 4.c of the IETF Trust's Legal Provisions 677 Relating to IETF Documents 678 (https://trustee.ietf.org/license-info). 680 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 681 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 682 'OPTIONAL' in the module text are to be interpreted as described 683 in RFC 2119 (https://tools.ietf.org/html/rfc2119). 685 This version of this YANG module is part of RFC XXXX 686 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 687 full legal notices."; 689 revision 2016-11-03 { 690 description 691 "Initial revision."; 692 reference 693 "RFC XXXX: A YANG Data Model for Routing Management"; 694 } 696 /* Features */ 698 feature multiple-ribs { 699 description 700 "This feature indicates that the server supports user-defined 701 RIBs. 703 Servers that do not advertise this feature SHOULD provide 704 exactly one system-controlled RIB per supported address family 705 and make them also the default RIBs. These RIBs then appear as 706 entries of the list /routing-state/ribs/rib."; 707 } 709 feature router-id { 710 description 711 "This feature indicates that the server supports configuration 712 of an explicit 32-bit router ID that is used by some routing 713 protocols. 715 Servers that do not advertise this feature set a router ID 716 algorithmically, usually to one of configured IPv4 addresses. 717 However, this algorithm is implementation-specific."; 718 } 720 /* Identities */ 722 identity address-family { 723 description 724 "Base identity from which identities describing address 725 families are derived."; 726 } 728 identity ipv4 { 729 base address-family; 730 description 731 "This identity represents IPv4 address family."; 732 } 734 identity ipv6 { 735 base address-family; 736 description 737 "This identity represents IPv6 address family."; 738 } 740 identity control-plane-protocol { 741 description 742 "Base identity from which control plane protocol identities are 743 derived."; 744 } 746 identity routing-protocol { 747 base control-plane-protocol; 748 description 749 "Identity from which Layer 3 routing protocol identities are 750 derived."; 751 } 753 identity direct { 754 base routing-protocol; 755 description 756 "Routing pseudo-protocol that provides routes to directly 757 connected networks."; 758 } 760 identity static { 761 base routing-protocol; 762 description 763 "Static routing pseudo-protocol."; 764 } 766 /* Type Definitions */ 768 typedef route-preference { 769 type uint32; 770 description 771 "This type is used for route preferences."; 772 } 774 /* Groupings */ 776 grouping address-family { 777 description 778 "This grouping provides a leaf identifying an address 779 family."; 780 leaf address-family { 781 type identityref { 782 base address-family; 783 } 784 mandatory "true"; 785 description 786 "Address family."; 787 } 788 } 790 grouping router-id { 791 description 792 "This grouping provides router ID."; 793 leaf router-id { 794 type yang:dotted-quad; 795 description 796 "A 32-bit number in the form of a dotted quad that is used by 797 some routing protocols identifying a router."; 798 reference 799 "RFC 2328: OSPF Version 2."; 800 } 801 } 803 grouping special-next-hop { 804 description 805 "This grouping provides a leaf with an enumeration of special 806 next-hops."; 807 leaf special-next-hop { 808 type enumeration { 809 enum blackhole { 810 description 811 "Silently discard the packet."; 812 } 813 enum unreachable { 814 description 815 "Discard the packet and notify the sender with an error 816 message indicating that the destination host is 817 unreachable."; 818 } 819 enum prohibit { 820 description 821 "Discard the packet and notify the sender with an error 822 message indicating that the communication is 823 administratively prohibited."; 824 } 825 enum receive { 826 description 827 "The packet will be received by the local system."; 828 } 829 } 830 description 831 "Special next-hop options."; 832 } 833 } 835 grouping next-hop-content { 836 description 837 "Generic parameters of next-hops in static routes."; 838 choice next-hop-options { 839 mandatory "true"; 840 description 841 "Options for next-hops in static routes. 843 It is expected that further cases will be added through 844 augments from other modules."; 845 case simple-next-hop { 846 description 847 "This case represents a simple next hop consisting of the 848 next-hop address and/or outgoing interface. 850 Modules for address families MUST augment this case with a 851 leaf containing a next-hop address of that address 852 family."; 853 leaf outgoing-interface { 854 type if:interface-ref; 855 description 856 "Name of the outgoing interface."; 857 } 858 } 859 case special-next-hop { 860 uses special-next-hop; 861 } 862 case next-hop-list { 863 container next-hop-list { 864 description 865 "Container for multiple next-hops."; 866 list next-hop { 867 key "index"; 868 description 869 "An entry of a next-hop list. 871 Modules for address families MUST augment this list 872 with a leaf containing a next-hop address of that 873 address family."; 874 leaf index { 875 type string; 876 description 877 "An user-specified identifier utilised to uniquely 878 reference the next-hop entry in the next-hop list. 879 The value of this index has no semantic meaning 880 other than for referencing the entry."; 881 } 882 leaf outgoing-interface { 883 type if:interface-ref; 884 description 885 "Name of the outgoing interface."; 886 } 887 } 888 } 889 } 890 } 891 } 892 grouping next-hop-state-content { 893 description 894 "Generic parameters of next-hops in state data."; 895 choice next-hop-options { 896 mandatory "true"; 897 description 898 "Options for next-hops in state data. 900 It is expected that further cases will be added through 901 augments from other modules, e.g., for recursive 902 next-hops."; 903 case simple-next-hop { 904 description 905 "This case represents a simple next hop consisting of the 906 next-hop address and/or outgoing interface. 908 Modules for address families MUST augment this case with a 909 leaf containing a next-hop address of that address 910 family."; 911 leaf outgoing-interface { 912 type if:interface-state-ref; 913 description 914 "Name of the outgoing interface."; 915 } 916 } 917 case special-next-hop { 918 uses special-next-hop; 919 } 920 case next-hop-list { 921 container next-hop-list { 922 description 923 "Container for multiple next-hops."; 924 list next-hop { 925 description 926 "An entry of a next-hop list. 928 Modules for address families MUST augment this list 929 with a leaf containing a next-hop address of that 930 address family."; 931 leaf outgoing-interface { 932 type if:interface-state-ref; 933 description 934 "Name of the outgoing interface."; 935 } 936 } 937 } 938 } 939 } 941 } 943 grouping route-metadata { 944 description 945 "Common route metadata."; 946 leaf source-protocol { 947 type identityref { 948 base routing-protocol; 949 } 950 mandatory "true"; 951 description 952 "Type of the routing protocol from which the route 953 originated."; 954 } 955 leaf active { 956 type empty; 957 description 958 "Presence of this leaf indicates that the route is preferred 959 among all routes in the same RIB that have the same 960 destination prefix."; 961 } 962 leaf last-updated { 963 type yang:date-and-time; 964 description 965 "Time stamp of the last modification of the route. If the 966 route was never modified, it is the time when the route was 967 inserted into the RIB."; 968 } 969 } 971 /* State data */ 973 container routing-state { 974 config "false"; 975 description 976 "State data of the routing subsystem."; 977 uses router-id { 978 description 979 "Global router ID. 981 It may be either configured or assigned algorithmically by 982 the implementation."; 983 } 984 container interfaces { 985 description 986 "Network layer interfaces used for routing."; 987 leaf-list interface { 988 type if:interface-state-ref; 989 description 990 "Each entry is a reference to the name of a configured 991 network layer interface."; 992 } 993 } 994 container control-plane-protocols { 995 description 996 "Container for the list of routing protocol instances."; 997 list control-plane-protocol { 998 key "type name"; 999 description 1000 "State data of a control plane protocol instance. 1002 An implementation MUST provide exactly one 1003 system-controlled instance of the 'direct' 1004 pseudo-protocol. Instances of other control plane 1005 protocols MAY be created by configuration."; 1006 leaf type { 1007 type identityref { 1008 base control-plane-protocol; 1009 } 1010 description 1011 "Type of the control plane protocol."; 1012 } 1013 leaf name { 1014 type string; 1015 description 1016 "The name of the control plane protocol instance. 1018 For system-controlled instances this name is persistent, 1019 i.e., it SHOULD NOT change across reboots."; 1020 } 1021 } 1022 } 1023 container ribs { 1024 description 1025 "Container for RIBs."; 1026 list rib { 1027 key "name"; 1028 min-elements "1"; 1029 description 1030 "Each entry represents a RIB identified by the 'name' key. 1031 All routes in a RIB MUST belong to the same address 1032 family. 1034 An implementation SHOULD provide one system-controlled 1035 default RIB for each supported address family."; 1036 leaf name { 1037 type string; 1038 description 1039 "The name of the RIB."; 1040 } 1041 uses address-family; 1042 leaf default-rib { 1043 if-feature "multiple-ribs"; 1044 type boolean; 1045 default "true"; 1046 description 1047 "This flag has the value of 'true' if and only if the RIB 1048 is the default RIB for the given address family. 1050 By default, control plane protocols place their routes 1051 in the default RIBs."; 1052 } 1053 container routes { 1054 description 1055 "Current content of the RIB."; 1056 list route { 1057 description 1058 "A RIB route entry. This data node MUST be augmented 1059 with information specific for routes of each address 1060 family."; 1061 leaf route-preference { 1062 type route-preference; 1063 description 1064 "This route attribute, also known as administrative 1065 distance, allows for selecting the preferred route 1066 among routes with the same destination prefix. A 1067 smaller value means a more preferred route."; 1068 } 1069 container next-hop { 1070 description 1071 "Route's next-hop attribute."; 1072 uses next-hop-state-content; 1073 } 1074 uses route-metadata; 1075 } 1076 } 1077 action active-route { 1078 description 1079 "Return the active RIB route that is used for the 1080 destination address. 1082 Address family specific modules MUST augment input 1083 parameters with a leaf named 'destination-address'."; 1084 output { 1085 container route { 1086 description 1087 "The active RIB route for the specified destination. 1089 If no route exists in the RIB for the destination 1090 address, no output is returned. 1092 Address family specific modules MUST augment this 1093 container with appropriate route contents."; 1094 container next-hop { 1095 description 1096 "Route's next-hop attribute."; 1097 uses next-hop-state-content; 1098 } 1099 uses route-metadata; 1100 } 1101 } 1102 } 1103 } 1104 } 1105 } 1107 /* Configuration Data */ 1109 container routing { 1110 description 1111 "Configuration parameters for the routing subsystem."; 1112 uses router-id { 1113 if-feature "router-id"; 1114 description 1115 "Configuration of the global router ID. Routing protocols 1116 that use router ID can use this parameter or override it 1117 with another value."; 1118 } 1119 container control-plane-protocols { 1120 description 1121 "Configuration of control plane protocol instances."; 1122 list control-plane-protocol { 1123 key "type name"; 1124 description 1125 "Each entry contains configuration of a control plane 1126 protocol instance."; 1127 leaf type { 1128 type identityref { 1129 base control-plane-protocol; 1130 } 1131 description 1132 "Type of the control plane protocol - an identity derived 1133 from the 'control-plane-protocol' base identity."; 1134 } 1135 leaf name { 1136 type string; 1137 description 1138 "An arbitrary name of the control plane protocol 1139 instance."; 1140 } 1141 leaf description { 1142 type string; 1143 description 1144 "Textual description of the control plane protocol 1145 instance."; 1146 } 1147 container static-routes { 1148 when "derived-from-or-self(../type, 'rt:static')" { 1149 description 1150 "This container is only valid for the 'static' routing 1151 protocol."; 1152 } 1153 description 1154 "Configuration of the 'static' pseudo-protocol. 1156 Address-family-specific modules augment this node with 1157 their lists of routes."; 1158 } 1159 } 1160 } 1161 container ribs { 1162 description 1163 "Configuration of RIBs."; 1164 list rib { 1165 key "name"; 1166 description 1167 "Each entry contains configuration for a RIB identified by 1168 the 'name' key. 1170 Entries having the same key as a system-controlled entry 1171 of the list /routing-state/ribs/rib are used for 1172 configuring parameters of that entry. Other entries define 1173 additional user-controlled RIBs."; 1174 leaf name { 1175 type string; 1176 description 1177 "The name of the RIB. 1179 For system-controlled entries, the value of this leaf 1180 must be the same as the name of the corresponding entry 1181 in state data. 1183 For user-controlled entries, an arbitrary name can be 1184 used."; 1185 } 1186 uses address-family { 1187 description 1188 "Address family of the RIB. 1190 It is mandatory for user-controlled RIBs. For 1191 system-controlled RIBs it can be omitted, otherwise it 1192 must match the address family of the corresponding state 1193 entry."; 1194 refine "address-family" { 1195 mandatory "false"; 1196 } 1197 } 1198 leaf description { 1199 type string; 1200 description 1201 "Textual description of the RIB."; 1202 } 1203 } 1204 } 1205 } 1206 } 1208 1210 8. IPv4 Unicast Routing Management YANG Module 1212 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1213 the actual RFC number and all occurrences of the revision date below 1214 with the date of RFC publication (and remove this note). 1216 file "ietf-ipv4-unicast-routing@2016-11-03.yang" 1218 module ietf-ipv4-unicast-routing { 1220 yang-version "1.1"; 1222 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1224 prefix "v4ur"; 1226 import ietf-routing { 1227 prefix "rt"; 1228 } 1229 import ietf-inet-types { 1230 prefix "inet"; 1231 } 1233 organization 1234 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1236 contact 1237 "WG Web: 1238 WG List: 1240 WG Chair: Lou Berger 1241 1243 WG Chair: Kent Watsen 1244 1246 Editor: Ladislav Lhotka 1247 1249 Editor: Acee Lindem 1250 "; 1252 description 1253 "This YANG module augments the 'ietf-routing' module with basic 1254 configuration and state data for IPv4 unicast routing. 1256 Copyright (c) 2016 IETF Trust and the persons identified as 1257 authors of the code. All rights reserved. 1259 Redistribution and use in source and binary forms, with or 1260 without modification, is permitted pursuant to, and subject to 1261 the license terms contained in, the Simplified BSD License set 1262 forth in Section 4.c of the IETF Trust's Legal Provisions 1263 Relating to IETF Documents 1264 (https://trustee.ietf.org/license-info). 1266 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1267 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1268 'OPTIONAL' in the module text are to be interpreted as described 1269 in RFC 2119 (https://tools.ietf.org/html/rfc2119). 1271 This version of this YANG module is part of RFC XXXX 1272 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1273 full legal notices."; 1275 revision 2016-11-03 { 1276 description 1277 "Initial revision."; 1278 reference 1279 "RFC XXXX: A YANG Data Model for Routing Management"; 1280 } 1282 /* Identities */ 1284 identity ipv4-unicast { 1285 base rt:ipv4; 1286 description 1287 "This identity represents the IPv4 unicast address family."; 1288 } 1290 /* State data */ 1292 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1293 when "derived-from-or-self(../../rt:address-family, " 1294 + "'v4ur:ipv4-unicast')" { 1295 description 1296 "This augment is valid only for IPv4 unicast."; 1297 } 1298 description 1299 "This leaf augments an IPv4 unicast route."; 1300 leaf destination-prefix { 1301 type inet:ipv4-prefix; 1302 description 1303 "IPv4 destination prefix."; 1304 } 1305 } 1307 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1308 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1309 when "derived-from-or-self(../../../rt:address-family, " 1310 + "'v4ur:ipv4-unicast')" { 1311 description 1312 "This augment is valid only for IPv4 unicast."; 1313 } 1314 description 1315 "Augment 'simple-next-hop' case in IPv4 unicast routes."; 1316 leaf next-hop-address { 1317 type inet:ipv4-address; 1318 description 1319 "IPv4 address of the next-hop."; 1320 } 1321 } 1323 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1324 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1325 + "rt:next-hop-list/rt:next-hop" { 1326 when "derived-from-or-self(../../../../../rt:address-family, " 1327 + "'v4ur:ipv4-unicast')" { 1328 description 1329 "This augment is valid only for IPv4 unicast."; 1330 } 1331 description 1332 "This leaf augments the 'next-hop-list' case of IPv4 unicast 1333 routes."; 1334 leaf address { 1335 type inet:ipv4-address; 1336 description 1337 "IPv4 address of the next-hop."; 1338 } 1339 } 1341 augment 1342 "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" { 1343 when "derived-from-or-self(../rt:address-family, " 1344 + "'v4ur:ipv4-unicast')" { 1345 description 1346 "This augment is valid only for IPv4 unicast RIBs."; 1347 } 1348 description 1349 "This augment adds the input parameter of the 'active-route' 1350 action."; 1351 leaf destination-address { 1352 type inet:ipv4-address; 1353 description 1354 "IPv4 destination address."; 1355 } 1356 } 1358 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1359 + "rt:output/rt:route" { 1360 when "derived-from-or-self(../../rt:address-family, " 1361 + "'v4ur:ipv4-unicast')" { 1362 description 1363 "This augment is valid only for IPv4 unicast."; 1364 } 1365 description 1366 "This augment adds the destination prefix to the reply of the 1367 'active-route' action."; 1368 leaf destination-prefix { 1369 type inet:ipv4-prefix; 1370 description 1371 "IPv4 destination prefix."; 1372 } 1374 } 1376 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1377 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1378 + "rt:simple-next-hop" { 1379 when "derived-from-or-self(../../../rt:address-family, " 1380 + "'v4ur:ipv4-unicast')" { 1381 description 1382 "This augment is valid only for IPv4 unicast."; 1383 } 1384 description 1385 "Augment 'simple-next-hop' case in the reply to the 1386 'active-route' action."; 1387 leaf next-hop-address { 1388 type inet:ipv4-address; 1389 description 1390 "IPv4 address of the next-hop."; 1391 } 1392 } 1394 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1395 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1396 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1397 when "derived-from-or-self(../../../../../rt:address-family, " 1398 + "'v4ur:ipv4-unicast')" { 1399 description 1400 "This augment is valid only for IPv4 unicast."; 1401 } 1402 description 1403 "Augment 'next-hop-list' case in the reply to the 1404 'active-route' action."; 1405 leaf next-hop-address { 1406 type inet:ipv4-address; 1407 description 1408 "IPv4 address of the next-hop."; 1409 } 1410 } 1412 /* Configuration data */ 1414 augment "/rt:routing/rt:control-plane-protocols/" 1415 + "rt:control-plane-protocol/rt:static-routes" { 1416 description 1417 "This augment defines the configuration of the 'static' 1418 pseudo-protocol with data specific to IPv4 unicast."; 1419 container ipv4 { 1420 description 1421 "Configuration of a 'static' pseudo-protocol instance 1422 consists of a list of routes."; 1423 list route { 1424 key "destination-prefix"; 1425 description 1426 "A list of static routes."; 1427 leaf destination-prefix { 1428 type inet:ipv4-prefix; 1429 mandatory "true"; 1430 description 1431 "IPv4 destination prefix."; 1432 } 1433 leaf description { 1434 type string; 1435 description 1436 "Textual description of the route."; 1437 } 1438 container next-hop { 1439 description 1440 "Configuration of next-hop."; 1441 uses rt:next-hop-content { 1442 augment "next-hop-options/simple-next-hop" { 1443 description 1444 "Augment 'simple-next-hop' case in IPv4 static 1445 routes."; 1446 leaf next-hop-address { 1447 type inet:ipv4-address; 1448 description 1449 "IPv4 address of the next-hop."; 1450 } 1451 } 1452 augment "next-hop-options/next-hop-list/next-hop-list/" 1453 + "next-hop" { 1454 description 1455 "Augment 'next-hop-list' case in IPv4 static 1456 routes."; 1457 leaf next-hop-address { 1458 type inet:ipv4-address; 1459 description 1460 "IPv4 address of the next-hop."; 1461 } 1462 } 1463 } 1464 } 1465 } 1466 } 1467 } 1468 } 1469 1471 9. IPv6 Unicast Routing Management YANG Module 1473 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1474 the actual RFC number and all occurrences of the revision date below 1475 with the date of RFC publication (and remove this note). 1477 file "ietf-ipv6-unicast-routing@2016-11-03.yang" 1479 module ietf-ipv6-unicast-routing { 1481 yang-version "1.1"; 1483 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1485 prefix "v6ur"; 1487 import ietf-routing { 1488 prefix "rt"; 1489 } 1491 import ietf-inet-types { 1492 prefix "inet"; 1493 } 1495 include ietf-ipv6-router-advertisements { 1496 revision-date 2016-11-03; 1497 } 1499 organization 1500 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1502 contact 1503 "WG Web: 1504 WG List: 1506 WG Chair: Lou Berger 1507 1509 WG Chair: Kent Watsen 1510 1512 Editor: Ladislav Lhotka 1513 1515 Editor: Acee Lindem 1516 "; 1518 description 1519 "This YANG module augments the 'ietf-routing' module with basic 1520 configuration and state data for IPv6 unicast routing. 1522 Copyright (c) 2016 IETF Trust and the persons identified as 1523 authors of the code. All rights reserved. 1525 Redistribution and use in source and binary forms, with or 1526 without modification, is permitted pursuant to, and subject to 1527 the license terms contained in, the Simplified BSD License set 1528 forth in Section 4.c of the IETF Trust's Legal Provisions 1529 Relating to IETF Documents 1530 (https://trustee.ietf.org/license-info). 1532 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1533 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1534 'OPTIONAL' in the module text are to be interpreted as described 1535 in RFC 2119 (https://tools.ietf.org/html/rfc2119). 1537 This version of this YANG module is part of RFC XXXX 1538 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1539 full legal notices."; 1541 revision 2016-11-03 { 1542 description 1543 "Initial revision."; 1544 reference 1545 "RFC XXXX: A YANG Data Model for Routing Management"; 1546 } 1548 /* Identities */ 1550 identity ipv6-unicast { 1551 base rt:ipv6; 1552 description 1553 "This identity represents the IPv6 unicast address family."; 1554 } 1556 /* State data */ 1558 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1559 when "derived-from-or-self(../../rt:address-family, " 1560 + "'v6ur:ipv6-unicast')" { 1561 description 1562 "This augment is valid only for IPv6 unicast."; 1563 } 1564 description 1565 "This leaf augments an IPv6 unicast route."; 1567 leaf destination-prefix { 1568 type inet:ipv6-prefix; 1569 description 1570 "IPv6 destination prefix."; 1571 } 1572 } 1574 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1575 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1576 when "derived-from-or-self(../../../rt:address-family, " 1577 + "'v6ur:ipv6-unicast')" { 1578 description 1579 "This augment is valid only for IPv6 unicast."; 1580 } 1581 description 1582 "Augment 'simple-next-hop' case in IPv6 unicast routes."; 1583 leaf next-hop-address { 1584 type inet:ipv6-address; 1585 description 1586 "IPv6 address of the next-hop."; 1587 } 1588 } 1590 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1591 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1592 + "rt:next-hop-list/rt:next-hop" { 1593 when "derived-from-or-self(../../../../../rt:address-family, " 1594 + "'v6ur:ipv6-unicast')" { 1595 description 1596 "This augment is valid only for IPv6 unicast."; 1597 } 1598 description 1599 "This leaf augments the 'next-hop-list' case of IPv6 unicast 1600 routes."; 1601 leaf address { 1602 type inet:ipv6-address; 1603 description 1604 "IPv6 address of the next-hop."; 1605 } 1606 } 1608 augment 1609 "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" { 1610 when "derived-from-or-self(../rt:address-family, " 1611 + "'v6ur:ipv6-unicast')" { 1612 description 1613 "This augment is valid only for IPv6 unicast RIBs."; 1614 } 1615 description 1616 "This augment adds the input parameter of the 'active-route' 1617 action."; 1618 leaf destination-address { 1619 type inet:ipv6-address; 1620 description 1621 "IPv6 destination address."; 1622 } 1623 } 1625 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1626 + "rt:output/rt:route" { 1627 when "derived-from-or-self(../../rt:address-family, " 1628 + "'v6ur:ipv6-unicast')" { 1629 description 1630 "This augment is valid only for IPv6 unicast."; 1631 } 1632 description 1633 "This augment adds the destination prefix to the reply of the 1634 'active-route' action."; 1635 leaf destination-prefix { 1636 type inet:ipv6-prefix; 1637 description 1638 "IPv6 destination prefix."; 1639 } 1640 } 1642 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1643 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1644 + "rt:simple-next-hop" { 1645 when "derived-from-or-self(../../../rt:address-family, " 1646 + "'v6ur:ipv6-unicast')" { 1647 description 1648 "This augment is valid only for IPv6 unicast."; 1649 } 1650 description 1651 "Augment 'simple-next-hop' case in the reply to the 1652 'active-route' action."; 1653 leaf next-hop-address { 1654 type inet:ipv6-address; 1655 description 1656 "IPv6 address of the next-hop."; 1657 } 1658 } 1660 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1661 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1662 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1664 when "derived-from-or-self(../../../../../rt:address-family, " 1665 + "'v6ur:ipv6-unicast')" { 1666 description 1667 "This augment is valid only for IPv6 unicast."; 1668 } 1669 description 1670 "Augment 'next-hop-list' case in the reply to the 1671 'active-route' action."; 1672 leaf next-hop-address { 1673 type inet:ipv6-address; 1674 description 1675 "IPv6 address of the next-hop."; 1676 } 1677 } 1679 /* Configuration data */ 1681 augment "/rt:routing/rt:control-plane-protocols/" 1682 + "rt:control-plane-protocol/rt:static-routes" { 1683 description 1684 "This augment defines the configuration of the 'static' 1685 pseudo-protocol with data specific to IPv6 unicast."; 1686 container ipv6 { 1687 description 1688 "Configuration of a 'static' pseudo-protocol instance 1689 consists of a list of routes."; 1690 list route { 1691 key "destination-prefix"; 1692 description 1693 "A list of static routes."; 1694 leaf destination-prefix { 1695 type inet:ipv6-prefix; 1696 mandatory "true"; 1697 description 1698 "IPv6 destination prefix."; 1699 } 1700 leaf description { 1701 type string; 1702 description 1703 "Textual description of the route."; 1704 } 1705 container next-hop { 1706 description 1707 "Configuration of next-hop."; 1708 uses rt:next-hop-content { 1709 augment "next-hop-options/simple-next-hop" { 1710 description 1711 "Augment 'simple-next-hop' case in IPv6 static 1712 routes."; 1713 leaf next-hop-address { 1714 type inet:ipv6-address; 1715 description 1716 "IPv6 address of the next-hop."; 1717 } 1718 } 1719 augment "next-hop-options/next-hop-list/next-hop-list/" 1720 + "next-hop" { 1721 description 1722 "Augment 'next-hop-list' case in IPv6 static 1723 routes."; 1724 leaf next-hop-address { 1725 type inet:ipv6-address; 1726 description 1727 "IPv6 address of the next-hop."; 1728 } 1729 } 1730 } 1731 } 1732 } 1733 } 1734 } 1735 } 1737 1739 9.1. IPv6 Router Advertisements Submodule 1741 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1742 the actual RFC number and all occurrences of the revision date below 1743 with the date of RFC publication (and remove this note). 1745 file "ietf-ipv6-router-advertisements@2016-11-03.yang" 1747 submodule ietf-ipv6-router-advertisements { 1749 yang-version "1.1"; 1751 belongs-to ietf-ipv6-unicast-routing { 1752 prefix "v6ur"; 1753 } 1755 import ietf-inet-types { 1756 prefix "inet"; 1757 } 1759 import ietf-interfaces { 1760 prefix "if"; 1761 } 1763 import ietf-ip { 1764 prefix "ip"; 1765 } 1767 organization 1768 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1770 contact 1771 "WG Web: 1772 WG List: 1774 WG Chair: Lou Berger 1775 1777 WG Chair: Kent Watsen 1778 1780 Editor: Ladislav Lhotka 1781 1783 Editor: Acee Lindem 1784 "; 1786 description 1787 "This YANG module augments the 'ietf-ip' module with 1788 configuration and state data of IPv6 router advertisements. 1790 Copyright (c) 2016 IETF Trust and the persons identified as 1791 authors of the code. All rights reserved. 1793 Redistribution and use in source and binary forms, with or 1794 without modification, is permitted pursuant to, and subject to 1795 the license terms contained in, the Simplified BSD License set 1796 forth in Section 4.c of the IETF Trust's Legal Provisions 1797 Relating to IETF Documents 1798 (https://trustee.ietf.org/license-info). 1800 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1801 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1802 'OPTIONAL' in the module text are to be interpreted as described 1803 in RFC 2119 (https://tools.ietf.org/html/rfc2119). 1805 This version of this YANG module is part of RFC XXXX 1806 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1807 full legal notices."; 1809 reference 1810 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)."; 1812 revision 2016-11-03 { 1813 description 1814 "Initial revision."; 1815 reference 1816 "RFC XXXX: A YANG Data Model for Routing Management"; 1817 } 1819 /* State data */ 1821 augment "/if:interfaces-state/if:interface/ip:ipv6" { 1822 description 1823 "Augment interface state data with parameters of IPv6 router 1824 advertisements."; 1825 container ipv6-router-advertisements { 1826 description 1827 "Parameters of IPv6 Router Advertisements."; 1828 leaf send-advertisements { 1829 type boolean; 1830 description 1831 "A flag indicating whether or not the router sends periodic 1832 Router Advertisements and responds to Router 1833 Solicitations."; 1834 } 1835 leaf max-rtr-adv-interval { 1836 type uint16 { 1837 range "4..1800"; 1838 } 1839 units "seconds"; 1840 description 1841 "The maximum time allowed between sending unsolicited 1842 multicast Router Advertisements from the interface."; 1843 } 1844 leaf min-rtr-adv-interval { 1845 type uint16 { 1846 range "3..1350"; 1847 } 1848 units "seconds"; 1849 description 1850 "The minimum time allowed between sending unsolicited 1851 multicast Router Advertisements from the interface."; 1852 } 1853 leaf managed-flag { 1854 type boolean; 1855 description 1856 "The value that is placed in the 'Managed address 1857 configuration' flag field in the Router Advertisement."; 1858 } 1859 leaf other-config-flag { 1860 type boolean; 1861 description 1862 "The value that is placed in the 'Other configuration' flag 1863 field in the Router Advertisement."; 1864 } 1865 leaf link-mtu { 1866 type uint32; 1867 description 1868 "The value that is placed in MTU options sent by the 1869 router. A value of zero indicates that no MTU options are 1870 sent."; 1871 } 1872 leaf reachable-time { 1873 type uint32 { 1874 range "0..3600000"; 1875 } 1876 units "milliseconds"; 1877 description 1878 "The value that is placed in the Reachable Time field in 1879 the Router Advertisement messages sent by the router. A 1880 value of zero means unspecified (by this router)."; 1881 } 1882 leaf retrans-timer { 1883 type uint32; 1884 units "milliseconds"; 1885 description 1886 "The value that is placed in the Retrans Timer field in the 1887 Router Advertisement messages sent by the router. A value 1888 of zero means unspecified (by this router)."; 1889 } 1890 leaf cur-hop-limit { 1891 type uint8; 1892 description 1893 "The value that is placed in the Cur Hop Limit field in the 1894 Router Advertisement messages sent by the router. A value 1895 of zero means unspecified (by this router)."; 1896 } 1897 leaf default-lifetime { 1898 type uint16 { 1899 range "0..9000"; 1900 } 1901 units "seconds"; 1902 description 1903 "The value that is placed in the Router Lifetime field of 1904 Router Advertisements sent from the interface, in seconds. 1906 A value of zero indicates that the router is not to be 1907 used as a default router."; 1908 } 1909 container prefix-list { 1910 description 1911 "A list of prefixes that are placed in Prefix Information 1912 options in Router Advertisement messages sent from the 1913 interface. 1915 By default, these are all prefixes that the router 1916 advertises via routing protocols as being on-link for the 1917 interface from which the advertisement is sent."; 1918 list prefix { 1919 key "prefix-spec"; 1920 description 1921 "Advertised prefix entry and its parameters."; 1922 leaf prefix-spec { 1923 type inet:ipv6-prefix; 1924 description 1925 "IPv6 address prefix."; 1926 } 1927 leaf valid-lifetime { 1928 type uint32; 1929 units "seconds"; 1930 description 1931 "The value that is placed in the Valid Lifetime in the 1932 Prefix Information option. The designated value of all 1933 1's (0xffffffff) represents infinity. 1935 An implementation SHOULD keep this value constant in 1936 consecutive advertisements except when it is 1937 explicitly changed in configuration."; 1938 } 1939 leaf on-link-flag { 1940 type boolean; 1941 description 1942 "The value that is placed in the on-link flag ('L-bit') 1943 field in the Prefix Information option."; 1944 } 1945 leaf preferred-lifetime { 1946 type uint32; 1947 units "seconds"; 1948 description 1949 "The value that is placed in the Preferred Lifetime in 1950 the Prefix Information option, in seconds. The 1951 designated value of all 1's (0xffffffff) represents 1952 infinity. 1954 An implementation SHOULD keep this value constant in 1955 consecutive advertisements except when it is 1956 explicitly changed in configuration."; 1957 } 1958 leaf autonomous-flag { 1959 type boolean; 1960 description 1961 "The value that is placed in the Autonomous Flag field 1962 in the Prefix Information option."; 1963 } 1964 } 1965 } 1966 } 1967 } 1969 /* Configuration data */ 1971 augment "/if:interfaces/if:interface/ip:ipv6" { 1972 description 1973 "Augment interface configuration with parameters of IPv6 router 1974 advertisements."; 1975 container ipv6-router-advertisements { 1976 description 1977 "Configuration of IPv6 Router Advertisements."; 1978 leaf send-advertisements { 1979 type boolean; 1980 default "false"; 1981 description 1982 "A flag indicating whether or not the router sends periodic 1983 Router Advertisements and responds to Router 1984 Solicitations."; 1985 reference 1986 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1987 AdvSendAdvertisements."; 1988 } 1989 leaf max-rtr-adv-interval { 1990 type uint16 { 1991 range "4..1800"; 1992 } 1993 units "seconds"; 1994 default "600"; 1995 description 1996 "The maximum time allowed between sending unsolicited 1997 multicast Router Advertisements from the interface."; 1998 reference 1999 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2000 MaxRtrAdvInterval."; 2001 } 2002 leaf min-rtr-adv-interval { 2003 type uint16 { 2004 range "3..1350"; 2005 } 2006 units "seconds"; 2007 must ". <= 0.75 * ../max-rtr-adv-interval" { 2008 description 2009 "The value MUST NOT be greater than 75 % of 2010 'max-rtr-adv-interval'."; 2011 } 2012 description 2013 "The minimum time allowed between sending unsolicited 2014 multicast Router Advertisements from the interface. 2016 The default value to be used operationally if this leaf is 2017 not configured is determined as follows: 2019 - if max-rtr-adv-interval >= 9 seconds, the default value 2020 is 0.33 * max-rtr-adv-interval; 2022 - otherwise it is 0.75 * max-rtr-adv-interval."; 2023 reference 2024 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2025 MinRtrAdvInterval."; 2026 } 2027 leaf managed-flag { 2028 type boolean; 2029 default "false"; 2030 description 2031 "The value to be placed in the 'Managed address 2032 configuration' flag field in the Router Advertisement."; 2033 reference 2034 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2035 AdvManagedFlag."; 2036 } 2037 leaf other-config-flag { 2038 type boolean; 2039 default "false"; 2040 description 2041 "The value to be placed in the 'Other configuration' flag 2042 field in the Router Advertisement."; 2043 reference 2044 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2045 AdvOtherConfigFlag."; 2046 } 2047 leaf link-mtu { 2048 type uint32; 2049 default "0"; 2050 description 2051 "The value to be placed in MTU options sent by the router. 2052 A value of zero indicates that no MTU options are sent."; 2053 reference 2054 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2055 AdvLinkMTU."; 2056 } 2057 leaf reachable-time { 2058 type uint32 { 2059 range "0..3600000"; 2060 } 2061 units "milliseconds"; 2062 default "0"; 2063 description 2064 "The value to be placed in the Reachable Time field in the 2065 Router Advertisement messages sent by the router. A value 2066 of zero means unspecified (by this router)."; 2067 reference 2068 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2069 AdvReachableTime."; 2070 } 2071 leaf retrans-timer { 2072 type uint32; 2073 units "milliseconds"; 2074 default "0"; 2075 description 2076 "The value to be placed in the Retrans Timer field in the 2077 Router Advertisement messages sent by the router. A value 2078 of zero means unspecified (by this router)."; 2079 reference 2080 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2081 AdvRetransTimer."; 2082 } 2083 leaf cur-hop-limit { 2084 type uint8; 2085 description 2086 "The value to be placed in the Cur Hop Limit field in the 2087 Router Advertisement messages sent by the router. A value 2088 of zero means unspecified (by this router). 2090 If this parameter is not configured, the device SHOULD use 2091 the value specified in IANA Assigned Numbers that was in 2092 effect at the time of implementation."; 2093 reference 2094 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2095 AdvCurHopLimit. 2097 IANA: IP Parameters, 2098 http://www.iana.org/assignments/ip-parameters"; 2099 } 2100 leaf default-lifetime { 2101 type uint16 { 2102 range "0..9000"; 2103 } 2104 units "seconds"; 2105 description 2106 "The value to be placed in the Router Lifetime field of 2107 Router Advertisements sent from the interface, in seconds. 2108 It MUST be either zero or between max-rtr-adv-interval and 2109 9000 seconds. A value of zero indicates that the router is 2110 not to be used as a default router. These limits may be 2111 overridden by specific documents that describe how IPv6 2112 operates over different link layers. 2114 If this parameter is not configured, the device SHOULD use 2115 a value of 3 * max-rtr-adv-interval."; 2116 reference 2117 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2118 AdvDefaultLifeTime."; 2119 } 2120 container prefix-list { 2121 description 2122 "Configuration of prefixes to be placed in Prefix 2123 Information options in Router Advertisement messages sent 2124 from the interface. 2126 Prefixes that are advertised by default but do not have 2127 their entries in the child 'prefix' list are advertised 2128 with the default values of all parameters. 2130 The link-local prefix SHOULD NOT be included in the list 2131 of advertised prefixes."; 2132 reference 2133 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2134 AdvPrefixList."; 2135 list prefix { 2136 key "prefix-spec"; 2137 description 2138 "Configuration of an advertised prefix entry."; 2139 leaf prefix-spec { 2140 type inet:ipv6-prefix; 2141 description 2142 "IPv6 address prefix."; 2143 } 2144 choice control-adv-prefixes { 2145 default "advertise"; 2146 description 2147 "The prefix either may be explicitly removed from the 2148 set of advertised prefixes, or parameters with which 2149 it is advertised may be specified (default case)."; 2150 leaf no-advertise { 2151 type empty; 2152 description 2153 "The prefix will not be advertised. 2155 This can be used for removing the prefix from the 2156 default set of advertised prefixes."; 2157 } 2158 case advertise { 2159 leaf valid-lifetime { 2160 type uint32; 2161 units "seconds"; 2162 default "2592000"; 2163 description 2164 "The value to be placed in the Valid Lifetime in 2165 the Prefix Information option. The designated 2166 value of all 1's (0xffffffff) represents 2167 infinity."; 2168 reference 2169 "RFC 4861: Neighbor Discovery for IP version 6 2170 (IPv6) - AdvValidLifetime."; 2171 } 2172 leaf on-link-flag { 2173 type boolean; 2174 default "true"; 2175 description 2176 "The value to be placed in the on-link flag 2177 ('L-bit') field in the Prefix Information 2178 option."; 2179 reference 2180 "RFC 4861: Neighbor Discovery for IP version 6 2181 (IPv6) - AdvOnLinkFlag."; 2182 } 2183 leaf preferred-lifetime { 2184 type uint32; 2185 units "seconds"; 2186 must ". <= ../valid-lifetime" { 2187 description 2188 "This value MUST NOT be greater than 2189 valid-lifetime."; 2190 } 2191 default "604800"; 2192 description 2193 "The value to be placed in the Preferred Lifetime 2194 in the Prefix Information option. The designated 2195 value of all 1's (0xffffffff) represents 2196 infinity."; 2197 reference 2198 "RFC 4861: Neighbor Discovery for IP version 6 2199 (IPv6) - AdvPreferredLifetime."; 2200 } 2201 leaf autonomous-flag { 2202 type boolean; 2203 default "true"; 2204 description 2205 "The value to be placed in the Autonomous Flag 2206 field in the Prefix Information option."; 2207 reference 2208 "RFC 4861: Neighbor Discovery for IP version 6 2209 (IPv6) - AdvAutonomousFlag."; 2210 } 2211 } 2212 } 2213 } 2214 } 2215 } 2216 } 2217 } 2219 2221 10. IANA Considerations 2223 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2224 actual RFC number (and remove this note). 2226 This document registers the following namespace URIs in the IETF XML 2227 registry [RFC3688]: 2229 -------------------------------------------------------------------- 2230 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2232 Registrant Contact: The IESG. 2234 XML: N/A, the requested URI is an XML namespace. 2235 -------------------------------------------------------------------- 2236 -------------------------------------------------------------------- 2237 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2239 Registrant Contact: The IESG. 2241 XML: N/A, the requested URI is an XML namespace. 2242 -------------------------------------------------------------------- 2244 -------------------------------------------------------------------- 2245 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2247 Registrant Contact: The IESG. 2249 XML: N/A, the requested URI is an XML namespace. 2250 -------------------------------------------------------------------- 2252 This document registers the following YANG modules in the YANG Module 2253 Names registry [RFC6020]: 2255 -------------------------------------------------------------------- 2256 name: ietf-routing 2257 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2258 prefix: rt 2259 reference: RFC XXXX 2260 -------------------------------------------------------------------- 2262 -------------------------------------------------------------------- 2263 name: ietf-ipv4-unicast-routing 2264 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2265 prefix: v4ur 2266 reference: RFC XXXX 2267 -------------------------------------------------------------------- 2269 -------------------------------------------------------------------- 2270 name: ietf-ipv6-unicast-routing 2271 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2272 prefix: v6ur 2273 reference: RFC XXXX 2274 -------------------------------------------------------------------- 2276 This document registers the following YANG submodule in the YANG 2277 Module Names registry [RFC6020]: 2279 -------------------------------------------------------------------- 2280 name: ietf-ipv6-router-advertisements 2281 parent: ietf-ipv6-unicast-routing 2282 reference: RFC XXXX 2283 -------------------------------------------------------------------- 2285 11. Security Considerations 2287 Configuration and state data conforming to the core routing data 2288 model (defined in this document) are designed to be accessed via a 2289 management protocol with secure transport layer, such as NETCONF 2290 [RFC6241]. The NETCONF access control model [RFC6536] provides the 2291 means to restrict access for particular NETCONF users to a pre- 2292 configured subset of all available NETCONF protocol operations and 2293 content. 2295 A number of configuration data nodes defined in the YANG modules 2296 belonging to the core routing data model are writable/creatable/ 2297 deletable (i.e., "config true" in YANG terms, which is the default). 2298 These data nodes may be considered sensitive or vulnerable in some 2299 network environments. Write operations to these data nodes, such as 2300 "edit-config" in NETCONF, can have negative effects on the network if 2301 the protocol operations are not properly protected. 2303 The vulnerable "config true" parameters and subtrees are the 2304 following: 2306 /routing/control-plane-protocols/control-plane-protocol: This list 2307 specifies the control plane protocols configured on a device. 2309 /routing/ribs/rib: This list specifies the RIBs configured for the 2310 device. 2312 Unauthorised access to any of these lists can adversely affect the 2313 routing subsystem of both the local device and the network. This may 2314 lead to network malfunctions, delivery of packets to inappropriate 2315 destinations and other problems. 2317 12. Acknowledgments 2319 The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean 2320 Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini, 2321 David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane 2322 Litkowski, Thomas Morin, Tom Petch, Yingzhen Qu, Bruno Rijsman, 2323 Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man- 2324 Kit Yeung and Jeffrey Zhang for their helpful comments and 2325 suggestions. 2327 13. References 2328 13.1. Normative References 2330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2331 Requirement Levels", BCP 14, RFC 2119, 2332 DOI 10.17487/RFC2119, March 1997, 2333 . 2335 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2336 DOI 10.17487/RFC3688, January 2004, 2337 . 2339 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2340 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2341 DOI 10.17487/RFC4861, September 2007, 2342 . 2344 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2345 the Network Configuration Protocol (NETCONF)", RFC 6020, 2346 DOI 10.17487/RFC6020, October 2010, 2347 . 2349 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2350 and A. Bierman, Ed., "Network Configuration Protocol 2351 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2352 . 2354 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2355 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2356 . 2358 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2359 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2360 . 2362 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 2363 RFC 7277, DOI 10.17487/RFC7277, June 2014, 2364 . 2366 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2367 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2368 . 2370 13.2. Informative References 2372 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2373 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 2374 January 2011, . 2376 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2377 Protocol (NETCONF) Access Control Model", RFC 6536, 2378 DOI 10.17487/RFC6536, March 2012, 2379 . 2381 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 2382 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 2383 . 2385 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2386 RFC 7951, DOI 10.17487/RFC7951, August 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 For hosts that are never intended to act as routers, the ability to 2526 turn on sending IPv6 router advertisements (Section 5.4) should be 2527 removed. 2529 Platforms with severely constrained resources may use deviations for 2530 restricting the data model, e.g., limiting the number of "static" 2531 control plane protocol instances. 2533 Appendix C. Example: Adding a New Control Plane Protocol 2535 This appendix demonstrates how the core routing data model can be 2536 extended to support a new control plane protocol. The YANG module 2537 "example-rip" shown below is intended as an illustration rather than 2538 a real definition of a data model for the RIP routing protocol. For 2539 the sake of brevity, this module does not obey all the guidelines 2540 specified in [RFC6087]. See also Section 5.3.2. 2542 module example-rip { 2544 yang-version "1.1"; 2546 namespace "http://example.com/rip"; 2548 prefix "rip"; 2550 import ietf-interfaces { 2551 prefix "if"; 2552 } 2554 import ietf-routing { 2555 prefix "rt"; 2556 } 2558 identity rip { 2559 base rt:routing-protocol; 2560 description 2561 "Identity for the RIP routing protocol."; 2562 } 2564 typedef rip-metric { 2565 type uint8 { 2566 range "0..16"; 2567 } 2568 } 2570 grouping route-content { 2571 description 2572 "This grouping defines RIP-specific route attributes."; 2573 leaf metric { 2574 type rip-metric; 2575 } 2576 leaf tag { 2577 type uint16; 2578 default "0"; 2579 description 2580 "This leaf may be used to carry additional info, e.g. AS 2581 number."; 2582 } 2583 } 2585 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 2586 when "derived-from-or-self(rt:source-protocol, 'rip:rip')" { 2587 description 2588 "This augment is only valid for a routes whose source 2589 protocol is RIP."; 2591 } 2592 description 2593 "RIP-specific route attributes."; 2594 uses route-content; 2595 } 2597 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 2598 + "rt:output/rt:route" { 2599 description 2600 "RIP-specific route attributes in the output of 'active-route' 2601 RPC."; 2602 uses route-content; 2603 } 2605 augment "/rt:routing/rt:control-plane-protocols/" 2606 + "rt:control-plane-protocol" { 2607 when "derived-from-or-self(rt:type,'rip:rip')" { 2608 description 2609 "This augment is only valid for a routing protocol instance 2610 of type 'rip'."; 2611 } 2612 container rip { 2613 presence "RIP configuration"; 2614 description 2615 "RIP instance configuration."; 2616 container interfaces { 2617 description 2618 "Per-interface RIP configuration."; 2619 list interface { 2620 key "name"; 2621 description 2622 "RIP is enabled on interfaces that have an entry in this 2623 list, unless 'enabled' is set to 'false' for that 2624 entry."; 2625 leaf name { 2626 type if:interface-ref; 2627 } 2628 leaf enabled { 2629 type boolean; 2630 default "true"; 2631 } 2632 leaf metric { 2633 type rip-metric; 2634 default "1"; 2635 } 2636 } 2637 } 2638 leaf update-interval { 2639 type uint8 { 2640 range "10..60"; 2641 } 2642 units "seconds"; 2643 default "30"; 2644 description 2645 "Time interval between periodic updates."; 2646 } 2647 } 2648 } 2649 } 2651 Appendix D. Data Tree Example 2653 This section contains an example instance data tree in the JSON 2654 encoding [RFC7951], containing both configuration and state data. 2655 The data conforms to a data model that is defined by the following 2656 YANG library specification [RFC7895]: 2658 { 2659 "ietf-yang-library:modules-state": { 2660 "module-set-id": "c2e1f54169aa7f36e1a6e8d0865d441d3600f9c4", 2661 "module": [ 2662 { 2663 "name": "ietf-routing", 2664 "revision": "2016-11-03", 2665 "feature": [ 2666 "multiple-ribs", 2667 "router-id" 2668 ], 2669 "namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", 2670 "conformance-type": "implement" 2671 }, 2672 { 2673 "name": "ietf-ipv4-unicast-routing", 2674 "revision": "2016-11-03", 2675 "namespace": 2676 "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing", 2677 "conformance-type": "implement" 2678 }, 2679 { 2680 "name": "ietf-ipv6-unicast-routing", 2681 "revision": "2016-11-03", 2682 "namespace": 2683 "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing", 2684 "conformance-type": "implement" 2685 }, 2686 { 2687 "name": "ietf-interfaces", 2688 "revision": "2014-05-08", 2689 "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", 2690 "conformance-type": "implement" 2691 }, 2692 { 2693 "name": "ietf-inet-types", 2694 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 2695 "revision": "2013-07-15", 2696 "conformance-type": "import" 2697 }, 2698 { 2699 "name": "ietf-yang-types", 2700 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2701 "revision": "2013-07-15", 2702 "conformance-type": "import" 2703 }, 2704 { 2705 "name": "iana-if-type", 2706 "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type", 2707 "revision": "", 2708 "conformance-type": "implement" 2709 }, 2710 { 2711 "name": "ietf-ip", 2712 "revision": "2014-06-16", 2713 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", 2714 "conformance-type": "implement" 2715 } 2716 ] 2717 } 2718 } 2720 A simple network set-up as shown in Figure 3 is assumed: router "A" 2721 uses static default routes with the "ISP" router as the next-hop. 2722 IPv6 router advertisements are configured only on the "eth1" 2723 interface and disabled on the upstream "eth0" interface. 2725 +-----------------+ 2726 | | 2727 | Router ISP | 2728 | | 2729 +--------+--------+ 2730 |2001:db8:0:1::2 2731 |192.0.2.2 2732 | 2733 | 2734 |2001:db8:0:1::1 2735 eth0|192.0.2.1 2736 +--------+--------+ 2737 | | 2738 | Router A | 2739 | | 2740 +--------+--------+ 2741 eth1|198.51.100.1 2742 |2001:db8:0:2::1 2743 | 2745 Figure 3: Example network configuration 2747 The instance data tree could then be as follows: 2749 { 2750 "ietf-interfaces:interfaces": { 2751 "interface": [ 2752 { 2753 "name": "eth0", 2754 "type": "iana-if-type:ethernetCsmacd", 2755 "description": "Uplink to ISP.", 2756 "ietf-ip:ipv4": { 2757 "address": [ 2758 { 2759 "ip": "192.0.2.1", 2760 "prefix-length": 24 2761 } 2762 ], 2763 "forwarding": true 2764 }, 2765 "ietf-ip:ipv6": { 2766 "address": [ 2767 { 2768 "ip": "2001:0db8:0:1::1", 2769 "prefix-length": 64 2770 } 2771 ], 2772 "forwarding": true, 2773 "autoconf": { 2774 "create-global-addresses": false 2775 } 2776 } 2777 }, 2778 { 2779 "name": "eth1", 2780 "type": "iana-if-type:ethernetCsmacd", 2781 "description": "Interface to the internal network.", 2782 "ietf-ip:ipv4": { 2783 "address": [ 2784 { 2785 "ip": "198.51.100.1", 2786 "prefix-length": 24 2787 } 2788 ], 2789 "forwarding": true 2790 }, 2791 "ietf-ip:ipv6": { 2792 "address": [ 2793 { 2794 "ip": "2001:0db8:0:2::1", 2795 "prefix-length": 64 2796 } 2797 ], 2798 "forwarding": true, 2799 "autoconf": { 2800 "create-global-addresses": false 2801 }, 2802 "ietf-ipv6-unicast-routing:ipv6-router-advertisements": { 2803 "send-advertisements": true 2804 } 2805 } 2806 } 2807 ] 2808 }, 2809 "ietf-interfaces:interfaces-state": { 2810 "interface": [ 2811 { 2812 "name": "eth0", 2813 "type": "iana-if-type:ethernetCsmacd", 2814 "phys-address": "00:0C:42:E5:B1:E9", 2815 "oper-status": "up", 2816 "statistics": { 2817 "discontinuity-time": "2015-10-24T17:11:27+02:00" 2818 }, 2819 "ietf-ip:ipv4": { 2820 "forwarding": true, 2821 "mtu": 1500, 2822 "address": [ 2823 { 2824 "ip": "192.0.2.1", 2825 "prefix-length": 24 2826 } 2827 ] 2828 }, 2829 "ietf-ip:ipv6": { 2830 "forwarding": true, 2831 "mtu": 1500, 2832 "address": [ 2833 { 2834 "ip": "2001:0db8:0:1::1", 2835 "prefix-length": 64 2836 } 2837 ], 2838 "ietf-ipv6-unicast-routing:ipv6-router-advertisements": { 2839 "send-advertisements": true, 2840 "prefix-list": { 2841 "prefix": [ 2842 { 2843 "prefix-spec": "2001:db8:0:2::/64" 2844 } 2845 ] 2846 } 2847 } 2848 } 2849 }, 2850 { 2851 "name": "eth1", 2852 "type": "iana-if-type:ethernetCsmacd", 2853 "phys-address": "00:0C:42:E5:B1:EA", 2854 "oper-status": "up", 2855 "statistics": { 2856 "discontinuity-time": "2015-10-24T17:11:29+02:00" 2857 }, 2858 "ietf-ip:ipv4": { 2859 "forwarding": true, 2860 "mtu": 1500, 2861 "address": [ 2862 { 2863 "ip": "198.51.100.1", 2864 "prefix-length": 24 2865 } 2866 ] 2867 }, 2868 "ietf-ip:ipv6": { 2869 "forwarding": true, 2870 "mtu": 1500, 2871 "address": [ 2872 { 2873 "ip": "2001:0db8:0:2::1", 2874 "prefix-length": 64 2875 } 2876 ], 2877 "ietf-ipv6-unicast-routing:ipv6-router-advertisements": { 2878 "send-advertisements": true, 2879 "prefix-list": { 2880 "prefix": [ 2881 { 2882 "prefix-spec": "2001:db8:0:2::/64" 2883 } 2884 ] 2885 } 2886 } 2887 } 2888 } 2889 ] 2890 }, 2891 "ietf-routing:routing": { 2892 "router-id": "192.0.2.1", 2893 "control-plane-protocols": { 2894 "control-plane-protocol": [ 2895 { 2896 "type": "ietf-routing:static", 2897 "name": "st0", 2898 "description": 2899 "Static routing is used for the internal network.", 2900 "static-routes": { 2901 "ietf-ipv4-unicast-routing:ipv4": { 2902 "route": [ 2903 { 2904 "destination-prefix": "0.0.0.0/0", 2905 "next-hop": { 2906 "next-hop-address": "192.0.2.2" 2907 } 2908 } 2909 ] 2910 }, 2911 "ietf-ipv6-unicast-routing:ipv6": { 2912 "route": [ 2913 { 2914 "destination-prefix": "::/0", 2915 "next-hop": { 2916 "next-hop-address": "2001:db8:0:1::2" 2918 } 2919 } 2920 ] 2921 } 2922 } 2923 } 2924 ] 2925 } 2926 }, 2927 "ietf-routing:routing-state": { 2928 "interfaces": { 2929 "interface": [ 2930 "eth0", 2931 "eth1" 2932 ] 2933 }, 2934 "control-plane-protocols": { 2935 "control-plane-protocol": [ 2936 { 2937 "type": "ietf-routing:static", 2938 "name": "st0" 2939 } 2940 ] 2941 }, 2942 "ribs": { 2943 "rib": [ 2944 { 2945 "name": "ipv4-master", 2946 "address-family": 2947 "ietf-ipv4-unicast-routing:ipv4-unicast", 2948 "default-rib": true, 2949 "routes": { 2950 "route": [ 2951 { 2952 "ietf-ipv4-unicast-routing:destination-prefix": 2953 "192.0.2.1/24", 2954 "next-hop": { 2955 "outgoing-interface": "eth0" 2956 }, 2957 "route-preference": 0, 2958 "source-protocol": "ietf-routing:direct", 2959 "last-updated": "2015-10-24T17:11:27+02:00" 2960 }, 2961 { 2962 "ietf-ipv4-unicast-routing:destination-prefix": 2963 "198.51.100.0/24", 2964 "next-hop": { 2965 "outgoing-interface": "eth1" 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": 2989 "ietf-ipv6-unicast-routing:ipv6-unicast", 2990 "default-rib": true, 2991 "routes": { 2992 "route": [ 2993 { 2994 "ietf-ipv6-unicast-routing:destination-prefix": 2995 "2001:db8:0:1::/64", 2996 "next-hop": { 2997 "outgoing-interface": "eth0" 2998 }, 2999 "source-protocol": "ietf-routing:direct", 3000 "route-preference": 0, 3001 "last-updated": "2015-10-24T17:11:27+02:00" 3002 }, 3003 { 3004 "ietf-ipv6-unicast-routing:destination-prefix": 3005 "2001:db8:0:2::/64", 3006 "next-hop": { 3007 "outgoing-interface": "eth1" 3008 }, 3009 "source-protocol": "ietf-routing:direct", 3010 "route-preference": 0, 3011 "last-updated": "2015-10-24T17:11:27+02:00" 3012 }, 3013 { 3014 "ietf-ipv6-unicast-routing:destination-prefix": 3016 "::/0", 3017 "next-hop": { 3018 "ietf-ipv6-unicast-routing:next-hop-address": 3019 "2001:db8:0:1::2" 3020 }, 3021 "source-protocol": "ietf-routing:static", 3022 "route-preference": 5, 3023 "last-updated": "2015-10-24T18:02:45+02:00" 3024 } 3025 ] 3026 } 3027 } 3028 ] 3029 } 3030 } 3031 } 3033 Appendix E. Change Log 3035 RFC Editor: Remove this section upon publication as an RFC. 3037 E.1. Changes Between Versions -24 and -25 3039 o Minor edits based on IETF Last Call reviews. 3041 E.2. Changes Between Versions -23 and -24 3043 o Fix paths in "when" expressions due to errata 4749 of RFC 7950. 3045 E.3. Changes Between Versions -22 and -23 3047 o Removed "route-tag" feature. 3049 o Removed next-hop classifiers. 3051 o Fixed invalid when expressions in augments. 3053 o In simple-next-hop, an address, outgoing interface or both can be 3054 specified. 3056 o RPC "fib-route" changed into RIB action "active-route". 3058 o The requirement that direct routes be always placed in default 3059 RIBs. 3061 E.4. Changes Between Versions -21 and -22 3063 o Added "next-hop-list" as a new case of the "next-hop-options" 3064 choice. 3066 o Renamed "routing protocol" to "control plane protocol" in both the 3067 YANG modules and I-D text. 3069 E.5. Changes Between Versions -20 and -21 3071 o Routing instances were removed. 3073 o IPv6 RA parameters were moved to the "ietf-ipv6-router- 3074 advertisements". 3076 E.6. Changes Between Versions -19 and -20 3078 o Assignment of L3 interfaces to routing instances is now part of 3079 interface configuration. 3081 o Next-hop options in configuration were aligned with state data. 3083 o It is recommended to enclose protocol-specific configuration in a 3084 presence container. 3086 E.7. Changes Between Versions -18 and -19 3088 o The leaf "route-preference" was removed from the "routing- 3089 protocol" container in both "routing" and "routing-state". 3091 o The "vrf-routing-instance" identity was added in support of a 3092 common routing-instance type in addition to the "default-routing- 3093 instance". 3095 o Removed "enabled" switch from "routing-protocol". 3097 E.8. Changes Between Versions -17 and -18 3099 o The container "ribs" was moved under "routing-instance" (in both 3100 "routing" and "routing-state"). 3102 o Typedefs "rib-ref" and "rib-state-ref" were removed. 3104 o Removed "recipient-ribs" (both state and configuration). 3106 o Removed "connected-ribs" from "routing-protocol" (both state and 3107 configuration). 3109 o Configuration and state data for IPv6 RA were moved under 3110 "if:interface" and "if:interface-state". 3112 o Assignment of interfaces to routing instances now use leaf-list 3113 rather than list (both config and state). The opposite reference 3114 from "if:interface" to "rt:routing-instance" was changed to a 3115 single leaf (an interface cannot belong to multiple routing 3116 instances). 3118 o Specification of a default RIB is now a simple flag under "rib" 3119 (both config and state). 3121 o Default RIBs are marked by a flag in state data. 3123 E.9. Changes Between Versions -16 and -17 3125 o Added Acee as a co-author. 3127 o Removed all traces of route filters. 3129 o Removed numeric IDs of list entries in state data. 3131 o Removed all next-hop cases except "simple-next-hop" and "special- 3132 next-hop". 3134 o Removed feature "multipath-routes". 3136 o Augmented "ietf-interfaces" module with a leaf-list of leafrefs 3137 pointing form state data of an interface entry to the routing 3138 instance(s) to which the interface is assigned. 3140 E.10. Changes Between Versions -15 and -16 3142 o Added 'type' as the second key component of 'routing-protocol', 3143 both in configuration and state data. 3145 o The restriction of no more than one connected RIB per address 3146 family was removed. 3148 o Removed the 'id' key of routes in RIBs. This list has no keys 3149 anymore. 3151 o Remove the 'id' key from static routes and make 'destination- 3152 prefix' the only key. 3154 o Added 'route-preference' as a new attribute of routes in RIB. 3156 o Added 'active' as a new attribute of routes in RIBs. 3158 o Renamed RPC operation 'active-route' to 'fib-route'. 3160 o Added 'route-preference' as a new parameter of routing protocol 3161 instances, both in configuration and state data. 3163 o Renamed identity 'rt:standard-routing-instance' to 'rt:default- 3164 routing-instance'. 3166 o Added next-hop lists to state data. 3168 o Added two cases for specifying next-hops indirectly - via a new 3169 RIB or a recursive list of next-hops. 3171 o Reorganized next-hop in static routes. 3173 o Removed all 'if-feature' statements from state data. 3175 E.11. Changes Between Versions -14 and -15 3177 o Removed all defaults from state data. 3179 o Removed default from 'cur-hop-limit' in config. 3181 E.12. Changes Between Versions -13 and -14 3183 o Removed dependency of 'connected-ribs' on the 'multiple-ribs' 3184 feature. 3186 o Removed default value of 'cur-hop-limit' in state data. 3188 o Moved parts of descriptions and all references on IPv6 RA 3189 parameters from state data to configuration. 3191 o Added reference to RFC 6536 in the Security section. 3193 E.13. Changes Between Versions -12 and -13 3195 o Wrote appendix about minimum implementation. 3197 o Remove "when" statement for IPv6 router interface state data - it 3198 was dependent on a config value that may not be present. 3200 o Extra container for the next-hop list. 3202 o Names rather than numeric ids are used for referring to list 3203 entries in state data. 3205 o Numeric ids are always declared as mandatory and unique. Their 3206 description states that they are ephemeral. 3208 o Descriptions of "name" keys in state data lists are required to be 3209 persistent. 3211 o 3213 o Removed "if-feature multiple-ribs;" from connected-ribs. 3215 o "rib-name" instead of "name" is used as the name of leafref nodes. 3217 o "next-hop" instead of "nexthop" or "gateway" used throughout, both 3218 in node names and text. 3220 E.14. Changes Between Versions -11 and -12 3222 o Removed feature "advanced-router" and introduced two features 3223 instead: "multiple-ribs" and "multipath-routes". 3225 o Unified the keys of config and state versions of "routing- 3226 instance" and "rib" lists. 3228 o Numerical identifiers of state list entries are not keys anymore, 3229 but they are constrained using the "unique" statement. 3231 o Updated acknowledgements. 3233 E.15. Changes Between Versions -10 and -11 3235 o Migrated address families from IANA enumerations to identities. 3237 o Terminology and node names aligned with the I2RS RIB model: router 3238 -> routing instance, routing table -> RIB. 3240 o Introduced uint64 keys for state lists: routing-instance, rib, 3241 route, nexthop. 3243 o Described the relationship between system-controlled and user- 3244 controlled list entries. 3246 o Feature "user-defined-routing-tables" changed into "advanced- 3247 router". 3249 o Made nexthop into a choice in order to allow for nexthop-list 3250 (I2RS requirement). 3252 o Added nexthop-list with entries having priorities (backup) and 3253 weights (load balancing). 3255 o Updated bibliography references. 3257 E.16. Changes Between Versions -09 and -10 3259 o Added subtree for state data ("/routing-state"). 3261 o Terms "system-controlled entry" and "user-controlled entry" 3262 defined and used. 3264 o New feature "user-defined-routing-tables". Nodes that are useful 3265 only with user-defined routing tables are now conditional. 3267 o Added grouping "router-id". 3269 o In routing tables, "source-protocol" attribute of routes now 3270 reports only protocol type, and its datatype is "identityref". 3272 o Renamed "main-routing-table" to "default-routing-table". 3274 E.17. Changes Between Versions -08 and -09 3276 o Fixed "must" expression for "connected-routing-table". 3278 o Simplified "must" expression for "main-routing-table". 3280 o Moved per-interface configuration of a new routing protocol under 3281 'routing-protocol'. This also affects the 'example-rip' module. 3283 E.18. Changes Between Versions -07 and -08 3285 o Changed reference from RFC6021 to RFC6021bis. 3287 E.19. Changes Between Versions -06 and -07 3289 o The contents of in Appendix D was updated: "eth[01]" 3290 is used as the value of "location", and "forwarding" is on for 3291 both interfaces and both IPv4 and IPv6. 3293 o The "must" expression for "main-routing-table" was modified to 3294 avoid redundant error messages reporting address family mismatch 3295 when "name" points to a non-existent routing table. 3297 o The default behavior for IPv6 RA prefix advertisements was 3298 clarified. 3300 o Changed type of "rt:router-id" to "ip:dotted-quad". 3302 o Type of "rt:router-id" changed to "yang:dotted-quad". 3304 o Fixed missing prefixes in XPath expressions. 3306 E.20. Changes Between Versions -05 and -06 3308 o Document title changed: "Configuration" was replaced by 3309 "Management". 3311 o New typedefs "routing-table-ref" and "route-filter-ref". 3313 o Double slashes "//" were removed from XPath expressions and 3314 replaced with the single "/". 3316 o Removed uniqueness requirement for "router-id". 3318 o Complete data tree is now in Appendix A. 3320 o Changed type of "source-protocol" from "leafref" to "string". 3322 o Clarified the relationship between routing protocol instances and 3323 connected routing tables. 3325 o Added a must constraint saying that a routing table connected to 3326 the direct pseudo-protocol must not be a main routing table. 3328 E.21. Changes Between Versions -04 and -05 3330 o Routing tables are now global, i.e., "routing-tables" is a child 3331 of "routing" rather than "router". 3333 o "must" statement for "static-routes" changed to "when". 3335 o Added "main-routing-tables" containing references to main routing 3336 tables for each address family. 3338 o Removed the defaults for "address-family" and "safi" and made them 3339 mandatory. 3341 o Removed the default for route-filter/type and made this leaf 3342 mandatory. 3344 o If there is no active route for a given destination, the "active- 3345 route" RPC returns no output. 3347 o Added "enabled" switch under "routing-protocol". 3349 o Added "router-type" identity and "type" leaf under "router". 3351 o Route attribute "age" changed to "last-updated", its type is 3352 "yang:date-and-time". 3354 o The "direct" pseudo-protocol is always connected to main routing 3355 tables. 3357 o Entries in the list of connected routing tables renamed from 3358 "routing-table" to "connected-routing-table". 3360 o Added "must" constraint saying that a routing table must not be 3361 its own recipient. 3363 E.22. Changes Between Versions -03 and -04 3365 o Changed "error-tag" for both RPC operations from "missing element" 3366 to "data-missing". 3368 o Removed the decrementing behavior for advertised IPv6 prefix 3369 parameters "valid-lifetime" and "preferred-lifetime". 3371 o Changed the key of the static route lists from "seqno" to "id" 3372 because the routes needn't be sorted. 3374 o Added 'must' constraint saying that "preferred-lifetime" must not 3375 be greater than "valid-lifetime". 3377 E.23. Changes Between Versions -02 and -03 3379 o Module "iana-afn-safi" moved to I-D "iana-if-type". 3381 o Removed forwarding table. 3383 o RPC "get-route" changed to "active-route". Its output is a list 3384 of routes (for multi-path routing). 3386 o New RPC "route-count". 3388 o For both RPCs, specification of negative responses was added. 3390 o Relaxed separation of router instances. 3392 o Assignment of interfaces to router instances needn't be disjoint. 3394 o Route filters are now global. 3396 o Added "allow-all-route-filter" for symmetry. 3398 o Added Section 6 about interactions with "ietf-interfaces" and 3399 "ietf-ip". 3401 o Added "router-id" leaf. 3403 o Specified the names for IPv4/IPv6 unicast main routing tables. 3405 o Route parameter "last-modified" changed to "age". 3407 o Added container "recipient-routing-tables". 3409 E.24. Changes Between Versions -01 and -02 3411 o Added module "ietf-ipv6-unicast-routing". 3413 o The example in Appendix D now uses IP addresses from blocks 3414 reserved for documentation. 3416 o Direct routes appear by default in the forwarding table. 3418 o Network layer interfaces must be assigned to a router instance. 3419 Additional interface configuration may be present. 3421 o The "when" statement is only used with "augment", "must" is used 3422 elsewhere. 3424 o Additional "must" statements were added. 3426 o The "route-content" grouping for IPv4 and IPv6 unicast now 3427 includes the material from the "ietf-routing" version via "uses 3428 rt:route-content". 3430 o Explanation of symbols in the tree representation of data model 3431 hierarchy. 3433 E.25. Changes Between Versions -00 and -01 3435 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 3437 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 3438 safi" module. 3440 o Names of some data nodes were changed, in particular "routing- 3441 process" is now "router". 3443 o The restriction of a single AFN/SAFI per router was lifted. 3445 o RPC operation "delete-route" was removed. 3447 o Illegal XPath references from "get-route" to the datastore were 3448 fixed. 3450 o Section "Security Considerations" was written. 3452 Authors' Addresses 3454 Ladislav Lhotka 3455 CZ.NIC 3457 Email: lhotka@nic.cz 3459 Acee Lindem 3460 Cisco Systems 3462 Email: acee@cisco.com