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