idnits 2.17.00 (12 Aug 2021) /tmp/idnits57444/draft-ietf-netmod-rfc8022bis-02.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 : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC8022, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2719 has weird spacing: '...-prefix ine...' == Line 2740 has weird spacing: '...-prefix ine...' -- The document date (November 30, 2017) is 1633 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 normative reference: RFC 8022 (Obsoleted by RFC 8349) -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) == Outdated reference: draft-ietf-netmod-revised-datastores has been published as RFC 8342 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group L. Lhotka 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track A. Lindem 5 Expires: June 3, 2018 Cisco Systems 6 Y. Qu 7 Futurewei Technologies, Inc. 8 November 30, 2017 10 A YANG Data Model for Routing Management (NDMA Version) 11 draft-ietf-netmod-rfc8022bis-02 13 Abstract 15 This document contains a specification of three YANG modules and one 16 submodule. Together they form the core routing data model that 17 serves as a framework for configuring and managing a routing 18 subsystem. It is expected that these modules will be augmented by 19 additional YANG modules defining data models for control-plane 20 protocols, route filters, and other functions. The core routing data 21 model provides common building blocks for such extensions -- routes, 22 Routing Information Bases (RIBs), and control-plane protocols. 24 This version of these YANG modules uses new names for these YANG 25 models. The main difference from the first version is that this 26 version fully conforms to the Network Management Datastore 27 Architecture (NMDA). Consequently, this document obsoletes RFC 8022. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 3, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 65 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 66 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 67 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 68 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. The Design of the Core Routing Data Model . . . . . . . . . . 6 70 4.1. System-Controlled and User-Controlled List Entries . . . 7 71 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 8 72 5.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.2. Routing Information Base (RIB) . . . . . . . . . . . . . 9 74 5.3. Control-Plane Protocol . . . . . . . . . . . . . . . . . 10 75 5.3.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 10 76 5.3.2. Defining New Control-Plane Protocols . . . . . . . . 10 77 5.4. Parameters of IPv6 Router Advertisements . . . . . . . . 11 78 6. Interactions with Other YANG Modules . . . . . . . . . . . . 12 79 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 12 80 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 13 81 7. Routing Management YANG Module . . . . . . . . . . . . . . . 13 82 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 28 83 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 35 84 9.1. IPv6 Router Advertisements Submodule . . . . . . . . . . 43 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 55 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 55 89 12.2. Informative References . . . . . . . . . . . . . . . . . 56 90 Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 58 91 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 61 92 Appendix C. Example: Adding a New Control-Plane Protocol . . . . 61 93 Appendix D. Data Tree Example . . . . . . . . . . . . . . . . . 64 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 72 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 97 1. Introduction 99 This document contains a specification of the following YANG modules: 101 o The "ietf-routing" module provides generic components of a routing 102 data model. 104 o The "ietf-ipv4-unicast-routing" module augments the "ietf-routing" 105 module with additional data specific to IPv4 unicast. 107 o The "ietf-ipv6-unicast-routing" module augments the "ietf-routing" 108 module with additional data specific to IPv6 unicast. Its 109 submodule "ietf-ipv6-router-advertisements" also augments the 110 "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277] modules with 111 IPv6 router configuration variables required by [RFC4861]. 113 These modules together define the so-called core routing data model, 114 which is intended as a basis for future data model development 115 covering more-sophisticated routing systems. While these three 116 modules can be directly used for simple IP devices with static 117 routing (see Appendix B), their main purpose is to provide essential 118 building blocks for more-complicated data models involving multiple 119 control-plane protocols, multicast routing, additional address 120 families, and advanced functions such as route filtering or policy 121 routing. To this end, it is expected that the core routing data 122 model will be augmented by numerous modules developed by various IETF 123 working groups. 125 This version of these YANG modules uses new names for these YANG 126 models. The main difference from the first version is that this 127 version fully conforms to the Network Management Datastore 128 Architecture (NMDA) [I-D.ietf-netmod-revised-datastores]. 129 Consequently, this document obsoletes RFC 8022 [RFC8022]. 131 2. Terminology and Notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 The following terms are defined in [RFC6241]: 139 o client 141 o message 142 o protocol operation 144 o server 146 The following terms are defined in [RFC7950]: 148 o action 150 o augment 152 o configuration data 154 o container 156 o container with presence 158 o data model 160 o data node 162 o feature 164 o leaf 166 o list 168 o mandatory node 170 o module 172 o schema tree 174 o state data 176 o RPC (Remote Procedure Call) operation 178 2.1. Glossary of New Terms 180 core routing data model: YANG data model comprising "ietf-routing", 181 "ietf-ipv4-unicast-routing", and "ietf-ipv6-unicast-routing" 182 modules. 184 direct route: a route to a directly connected network. 186 Routing Information Base (RIB): An object containing a list of 187 routes together with other information. See Section 5.2 for 188 details. 190 system-controlled entry: An entry of a list in operational state 191 ("config false") that is created by the system independently of 192 what has been explicitly configured. See Section 4.1 for details. 194 user-controlled entry: An entry of a list in operational state data 195 ("config false") that is created and deleted as a direct 196 consequence of certain configuration changes. See Section 4.1 for 197 details. 199 2.2. Tree Diagrams 201 A simplified graphical representation of the complete data tree is 202 presented in Appendix A, and similar diagrams of its various subtrees 203 appear in the main text. 205 o Brackets "[" and "]" enclose list keys. 207 o Curly braces "{" and "}" contain names of optional features that 208 make the corresponding node conditional. 210 o Abbreviations before data node names: "rw" means configuration 211 (read-write), "ro" state data (read-only), "-x" RPC operations or 212 actions, and "-n" notifications. 214 o Symbols after data node names: "?" means an optional node, "!" a 215 container with presence, and "*" denotes a "list" or "leaf-list". 217 o Parentheses enclose choice and case nodes, and case nodes are also 218 marked with a colon (":"). 220 o Ellipsis ("...") stands for contents of subtrees that are not 221 shown. 223 2.3. Prefixes in Data Node Names 225 In this document, names of data nodes, actions, and other data model 226 objects are often used without a prefix, as long as it is clear from 227 the context in which YANG module each name is defined. Otherwise, 228 names are prefixed using the standard prefix associated with the 229 corresponding YANG module, as shown in Table 1. 231 +--------+---------------------------+-----------+ 232 | Prefix | YANG module | Reference | 233 +--------+---------------------------+-----------+ 234 | if | ietf-interfaces | [RFC7223] | 235 | ip | ietf-ip | [RFC7277] | 236 | rt | ietf-routing | Section 7 | 237 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 238 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 239 | yang | ietf-yang-types | [RFC6991] | 240 | inet | ietf-inet-types | [RFC6991] | 241 +--------+---------------------------+-----------+ 243 Table 1: Prefixes and Corresponding YANG Modules 245 3. Objectives 247 The initial design of the core routing data model was driven by the 248 following objectives: 250 o The data model should be suitable for the common address families 251 -- in particular, IPv4 and IPv6 -- and for unicast and multicast 252 routing, as well as Multiprotocol Label Switching (MPLS). 254 o A simple IP routing system, such as one that uses only static 255 routing, should be configurable in a simple way, ideally without 256 any need to develop additional YANG modules. 258 o On the other hand, the core routing framework must allow for 259 complicated implementations involving multiple Routing Information 260 Bases (RIBs) and multiple control-plane protocols, as well as 261 controlled redistributions of routing information. 263 o Because device vendors will want to map the data models built on 264 this generic framework to their proprietary data models and 265 configuration interfaces, the framework should be flexible enough 266 to facilitate that and accommodate data models with different 267 logic. 269 4. The Design of the Core Routing Data Model 271 The core routing data model consists of three YANG modules and one 272 submodule. The first module, "ietf-routing", defines the generic 273 components of a routing system. The other two modules, "ietf-ipv4- 274 unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf- 275 routing" module with additional data nodes that are needed for IPv4 276 and IPv6 unicast routing, respectively. The "ietf-ipv6-unicast- 277 routing" module has a submodule, "ietf-ipv6-router-advertisements", 278 that augments the "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277] 279 modules with configuration variables for IPv6 router advertisements 280 as required by [RFC4861]. 282 Figure 1 shows abridged views of the hierarchies. See Appendix A 283 for the complete data trees. 285 +--rw routing 286 +--rw router-id? yang:dotted-quad 287 +--ro interfaces 288 | +--ro interface* if:interface-ref 289 +--rw control-plane-protocols 290 | +--rw control-plane-protocol* [type name] 291 | +--rw type identityref 292 | +--rw name string 293 | +--rw description? string 294 | +--rw static-routes 295 | +--rw v4ur:ipv4 296 | | ... 297 | +--rw v6ur:ipv6 298 | ... 299 +--rw ribs 300 +--rw rib* [name] 301 +--rw name string 302 +--rw address-family? identityref 303 +--ro default-rib? boolean {multiple-ribs}? 304 +--ro routes 305 | +--ro route* 306 | ... 307 +---x active-route 308 | +---w input 309 | | +---w v4ur:destination-address? inet:ipv4-address 310 | | +---w v6ur:destination-address? inet:ipv6-address 311 | +--ro output 312 | ... 313 +--rw description? string 315 Figure 1: Data Hierarchy 317 As can be seen from Figures 1, the core routing data model introduces 318 several generic components of a routing framework: routes, RIBs 319 containing lists of routes, and control-plane protocols. Section 5 320 describes these components in more detail. 322 4.1. System-Controlled and User-Controlled List Entries 324 The core routing data model defines several lists in the schema tree, 325 such as "rib", that have to be populated with at least one entry in 326 any properly functioning device, and additional entries may be 327 configured by a client. 329 In such a list, the server creates the required item as a so-called 330 system-controlled entry in state data in the operational datastore 331 [I-D.ietf-netmod-revised-datastores], i.e., inside read-only lists in 332 the "routing" container. 334 An example can be seen in Appendix D: the "/routing/ribs/rib" list 335 has two system-controlled entries named "ipv4-master" and 336 "ipv6-master". 338 Additional entries may be created in the configuration by a client, 339 e.g., via the NETCONF protocol. These are so-called user-controlled 340 entries. If the server accepts a configured user-controlled entry, 341 then this entry also appears in the state data version of the list. 343 Corresponding entries in both versions of the list (in operational 344 datastore and intended datastore [I-D.ietf-netmod-revised-datastores] 345 have the same value of the list key. 347 A client may also provide supplemental configuration of system- 348 controlled entries. To do so, the client creates a new entry in the 349 configuration with the desired contents. In order to bind this entry 350 to the corresponding entry in the state data list in the operational 351 datastore, the key of the configuration entry has to be set to the 352 same value as the key of the state entry. 354 Deleting a user-controlled entry from the configuration list results 355 in the removal of the corresponding entry in the state data list. In 356 contrast, if client delets a system-controlled entry from the 357 configuration list in the intended datastore, only the extra 358 configuration specified in that entry is removed but the 359 corresponding state data entry remains in the list in the operational 360 datastore. 362 5. Basic Building Blocks 364 This section describes the essential components of the core routing 365 data model. 367 5.1. Route 369 Routes are basic elements of information in a routing system. The 370 core routing data model defines only the following minimal set of 371 route attributes: 373 o "destination-prefix": address prefix specifying the set of 374 destination addresses for which the route may be used. This 375 attribute is mandatory. 377 o "route-preference": an integer value (also known as administrative 378 distance) that is used for selecting a preferred route among 379 routes with the same destination prefix. A lower value means a 380 more preferred route. 382 o "next-hop": determines the outgoing interface and/or next-hop 383 address(es), or a special operation to be performed with a packet. 385 Routes are primarily state data that appear as entries of RIBs 386 (Section 5.2) but they may also be found in configuration data, for 387 example, as manually configured static routes. In the latter case, 388 configurable route attributes are generally a subset of attributes 389 defined for RIB routes. 391 5.2. Routing Information Base (RIB) 393 Every implementation of the core routing data model manages one or 394 more Routing Information Bases (RIBs). A RIB is a list of routes 395 complemented with administrative data. Each RIB contains only routes 396 of one address family. An address family is represented by an 397 identity derived from the "rt:address-family" base identity. 399 In the core routing data model, RIBs are state data represented as 400 entries of the list "/routing/ribs/rib" in the operational datastore 401 [I-D.ietf-netmod-revised-datastores]. The contents of RIBs are 402 controlled and manipulated by control-plane protocol operations that 403 may result in route additions, removals, and modifications. This 404 also includes manipulations via the "static" and/or "direct" pseudo- 405 protocols; see Section 5.3.1. 407 For every supported address family, exactly one RIB MUST be marked as 408 the so-called default RIB to which control-plane protocols place 409 their routes by default. 411 Simple router implementations that do not advertise the feature 412 "multiple-ribs" will typically create one system-controlled RIB per 413 supported address family and mark it as the default RIB. 415 More-complex router implementations advertising the "multiple-ribs" 416 feature support multiple RIBs per address family that can be used for 417 policy routing and other purposes. 419 The following action (see Section 7.15 of [RFC7950]) is defined for 420 the "rib" list: 422 o active-route -- return the active RIB route for the destination 423 address that is specified as the action's input parameter. 425 5.3. Control-Plane Protocol 427 The core routing data model provides an open-ended framework for 428 defining multiple control-plane protocol instances, e.g., for Layer 3 429 routing protocols. Each control-plane protocol instance MUST be 430 assigned a type, which is an identity derived from the 431 "rt:control-plane-protocol" base identity. The core routing data 432 model defines two identities for the direct and static pseudo- 433 protocols (Section 5.3.1). 435 Multiple control-plane protocol instances of the same type MAY be 436 configured. 438 5.3.1. Routing Pseudo-Protocols 440 The core routing data model defines two special routing protocol 441 types -- "direct" and "static". Both are in fact pseudo-protocols, 442 which means that they are confined to the local device and do not 443 exchange any routing information with adjacent routers. 445 Every implementation of the core routing data model MUST provide 446 exactly one instance of the "direct" pseudo-protocol type. It is the 447 source of direct routes for all configured address families. Direct 448 routes are normally supplied by the operating system kernel, based on 449 the configuration of network interface addresses; see Section 6.2. 451 A pseudo-protocol of the type "static" allows for specifying routes 452 manually. It MAY be configured in zero or multiple instances, 453 although a typical configuration will have exactly one instance. 455 5.3.2. Defining New Control-Plane Protocols 457 It is expected that future YANG modules will create data models for 458 additional control-plane protocol types. Such a new module has to 459 define the protocol-specific configuration and state data, and it has 460 to integrate it into the core routing framework in the following way: 462 o A new identity MUST be defined for the control-plane protocol, and 463 its base identity MUST be set to "rt:control-plane-protocol" or to 464 an identity derived from "rt:control-plane-protocol". 466 o Additional route attributes MAY be defined, preferably in one 467 place by means of defining a YANG grouping. The new attributes 468 have to be inserted by augmenting the definitions of the node 469 /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route 471 and possibly other places in the configuration, state data, 472 notifications, and input/output parameters of actions or RPC 473 operations. 475 o Configuration parameters and/or state data for the new protocol 476 can be defined by augmenting the "control-plane-protocol" data 477 node under "/routing". 479 By using a "when" statement, the augmented configuration parameters 480 and state data specific to the new protocol SHOULD be made 481 conditional and valid only if the value of "rt:type" or 482 "rt:source-protocol" is equal to (or derived from) the new protocol's 483 identity. 485 It is also RECOMMENDED that protocol-specific data nodes be 486 encapsulated in an appropriately named container with presence. Such 487 a container may contain mandatory data nodes that are otherwise 488 forbidden at the top level of an augment. 490 The above steps are implemented by the example YANG module for the 491 Routing Information Protocol (RIP) in Appendix C. 493 5.4. Parameters of IPv6 Router Advertisements 495 YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is 496 a submodule of the "ietf-ipv6-unicast-routing" module, augments the 497 configuration and state data of IPv6 interfaces with definitions of 498 the following variables as required by Section 6.2.1 of [RFC4861]: 500 o send-advertisements 502 o max-rtr-adv-interval 504 o min-rtr-adv-interval 506 o managed-flag 508 o other-config-flag 510 o link-mtu 512 o reachable-time 514 o retrans-timer 516 o cur-hop-limit 517 o default-lifetime 519 o prefix-list: a list of prefixes to be advertised. 521 The following parameters are associated with each prefix in the 522 list: 524 * valid-lifetime 526 * on-link-flag 528 * preferred-lifetime 530 * autonomous-flag 532 NOTES: 534 1. The "IsRouter" flag, which is also required by [RFC4861], is 535 implemented in the "ietf-ip" module [RFC7277] (leaf 536 "ip:forwarding"). 538 2. The original specification [RFC4861] allows the implementations 539 to decide whether the "valid-lifetime" and "preferred-lifetime" 540 parameters remain the same in consecutive advertisements or 541 decrement in real time. However, the latter behavior seems 542 problematic because the values might be reset again to the 543 (higher) configured values after a configuration is reloaded. 544 Moreover, no implementation is known to use the decrementing 545 behavior. The "ietf-ipv6-router-advertisements" submodule 546 therefore stipulates the former behavior with constant values. 548 6. Interactions with Other YANG Modules 550 The semantics of the core routing data model also depends on several 551 configuration parameters that are defined in other YANG modules. 553 6.1. Module "ietf-interfaces" 555 The following boolean switch is defined in the "ietf-interfaces" YANG 556 module [RFC7223]: 558 /if:interfaces/if:interface/if:enabled 560 If this switch is set to "false" for a network-layer interface, 561 then all routing and forwarding functions MUST be disabled on this 562 interface. 564 6.2. Module "ietf-ip" 566 The following boolean switches are defined in the "ietf-ip" YANG 567 module [RFC7277]: 569 /if:interfaces/if:interface/ip:ipv4/ip:enabled 571 If this switch is set to "false" for a network-layer interface, 572 then all IPv4 routing and forwarding functions MUST be disabled on 573 this interface. 575 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 577 If this switch is set to "false" for a network-layer interface, 578 then the forwarding of IPv4 datagrams through this interface MUST 579 be disabled. However, the interface MAY participate in other IPv4 580 routing functions, such as routing protocols. 582 /if:interfaces/if:interface/ip:ipv6/ip:enabled 584 If this switch is set to "false" for a network-layer interface, 585 then all IPv6 routing and forwarding functions MUST be disabled on 586 this interface. 588 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 590 If this switch is set to "false" for a network-layer interface, 591 then the forwarding of IPv6 datagrams through this interface MUST 592 be disabled. However, the interface MAY participate in other IPv6 593 routing functions, such as routing protocols. 595 In addition, the "ietf-ip" module allows for configuring IPv4 and 596 IPv6 addresses and network prefixes or masks on network-layer 597 interfaces. Configuration of these parameters on an enabled 598 interface MUST result in an immediate creation of the corresponding 599 direct route. The destination prefix of this route is set according 600 to the configured IP address and network prefix/mask, and the 601 interface is set as the outgoing interface for that route. 603 7. Routing Management YANG Module 605 file "ietf-routing@2017-11-30.yang" 606 module ietf-routing { 607 yang-version "1.1"; 608 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 609 prefix "rt"; 611 import ietf-yang-types { 612 prefix "yang"; 613 } 615 import ietf-interfaces { 616 prefix "if"; 617 } 619 organization 620 "IETF NETMOD - Networking Modeling Working Group"; 621 contact 622 "WG Web: 623 WG List: 625 Editor: Ladislav Lhotka 626 627 Acee Lindem 628 629 Yingzhen Qu 630 "; 632 description 633 "This YANG module defines essential components for the management 634 of a routing subsystem. 636 Copyright (c) 2017 IETF Trust and the persons 637 identified as authors of the code. All rights reserved. 639 Redistribution and use in source and binary forms, with or 640 without modification, is permitted pursuant to, and subject 641 to the license terms contained in, the Simplified BSD License 642 set forth in Section 4.c of the IETF Trust's Legal Provisions 643 Relating to IETF Documents 644 (http://trustee.ietf.org/license-info). 646 This version of this YANG module is part of RFC XXXX; see 647 the RFC itself for full legal notices."; 648 reference "RFC XXXX"; 650 revision 2017-10-30 { 651 description 652 "Network Managment Datastore Architecture (NDMA) Revision"; 653 reference 654 "RFC XXXX: A YANG Data Model for Routing Management 655 (NDMA Version)"; 656 } 658 revision 2016-11-04 { 659 description 660 "Initial revision."; 661 reference 662 "RFC 8022: A YANG Data Model for Routing Management"; 663 } 665 /* Features */ 666 feature multiple-ribs { 667 description 668 "This feature indicates that the server supports user-defined 669 RIBs. 671 Servers that do not advertise this feature SHOULD provide 672 exactly one system-controlled RIB per supported address family 673 and make it also the default RIB. This RIB then appears as an 674 entry of the list /routing/ribs/rib."; 675 } 677 feature router-id { 678 description 679 "This feature indicates that the server supports configuration 680 of an explicit 32-bit router ID that is used by some routing 681 protocols. 683 Servers that do not advertise this feature set a router ID 684 algorithmically, usually to one of the configured IPv4 685 addresses. However, this algorithm is implementation 686 specific."; 687 } 689 /* Identities */ 691 identity address-family { 692 description 693 "Base identity from which identities describing address 694 families are derived."; 695 } 697 identity ipv4 { 698 base rt:address-family; 699 description 700 "This identity represents IPv4 address family."; 701 } 703 identity ipv6 { 704 base rt:address-family; 705 description 706 "This identity represents IPv6 address family."; 707 } 708 identity control-plane-protocol { 709 description 710 "Base identity from which control-plane protocol identities are 711 derived."; 712 } 714 identity routing-protocol { 715 base rt:control-plane-protocol; 716 description 717 "Identity from which Layer 3 routing protocol identities are 718 derived."; 719 } 721 identity direct { 722 base rt:routing-protocol; 723 description 724 "Routing pseudo-protocol that provides routes to directly 725 connected networks."; 726 } 728 identity static { 729 base rt:routing-protocol; 730 description 731 "Static routing pseudo-protocol."; 732 } 734 /* Type Definitions */ 736 typedef route-preference { 737 type uint32; 738 description 739 "This type is used for route preferences."; 740 } 742 /* Groupings */ 744 grouping address-family { 745 description 746 "This grouping provides a leaf identifying an address 747 family."; 748 leaf address-family { 749 type identityref { 750 base rt:address-family; 751 } 752 mandatory "true"; 753 description 754 "Address family."; 755 } 757 } 759 grouping router-id { 760 description 761 "This grouping provides router ID."; 762 leaf router-id { 763 type yang:dotted-quad; 764 description 765 "A 32-bit number in the form of a dotted quad that is used by 766 some routing protocols identifying a router."; 767 reference 768 "RFC 2328: OSPF Version 2."; 769 } 770 } 772 grouping special-next-hop { 773 description 774 "This grouping provides a leaf with an enumeration of special 775 next hops."; 776 leaf special-next-hop { 777 type enumeration { 778 enum blackhole { 779 description 780 "Silently discard the packet."; 781 } 782 enum unreachable { 783 description 784 "Discard the packet and notify the sender with an error 785 message indicating that the destination host is 786 unreachable."; 787 } 788 enum prohibit { 789 description 790 "Discard the packet and notify the sender with an error 791 message indicating that the communication is 792 administratively prohibited."; 793 } 794 enum receive { 795 description 796 "The packet will be received by the local system."; 797 } 798 } 799 description 800 "Options for special next hops."; 801 } 802 } 804 grouping next-hop-content { 805 description 806 "Generic parameters of next hops in static routes."; 807 choice next-hop-options { 808 mandatory "true"; 809 description 810 "Options for next hops in static routes. 812 It is expected that further cases will be added through 813 augments from other modules."; 814 case simple-next-hop { 815 description 816 "This case represents a simple next hop consisting of the 817 next-hop address and/or outgoing interface. 819 Modules for address families MUST augment this case with a 820 leaf containing a next-hop address of that address 821 family."; 822 leaf outgoing-interface { 823 type if:interface-ref; 824 description 825 "Name of the outgoing interface."; 826 } 827 } 828 case special-next-hop { 829 uses special-next-hop; 830 } 831 case next-hop-list { 832 container next-hop-list { 833 description 834 "Container for multiple next-hops."; 835 list next-hop { 836 key "index"; 837 description 838 "An entry of a next-hop list. 840 Modules for address families MUST augment this list 841 with a leaf containing a next-hop address of that 842 address family."; 843 leaf index { 844 type string; 845 description 846 "A user-specified identifier utilized to uniquely 847 reference the next-hop entry in the next-hop list. 848 The value of this index has no semantic meaning 849 other than for referencing the entry."; 850 } 851 leaf outgoing-interface { 852 type if:interface-ref; 853 description 854 "Name of the outgoing interface."; 855 } 856 } 857 } 858 } 859 } 860 } 862 grouping next-hop-state-content { 863 description 864 "Generic parameters of next hops in state data."; 865 choice next-hop-options { 866 mandatory "true"; 867 description 868 "Options for next hops in state data. 870 It is expected that further cases will be added through 871 augments from other modules, e.g., for recursive 872 next hops."; 873 case simple-next-hop { 874 description 875 "This case represents a simple next hop consisting of the 876 next-hop address and/or outgoing interface. 878 Modules for address families MUST augment this case with a 879 leaf containing a next-hop address of that address 880 family."; 881 leaf outgoing-interface { 882 type if:interface-ref; 883 description 884 "Name of the outgoing interface."; 885 } 886 } 887 case special-next-hop { 888 uses special-next-hop; 889 } 890 case next-hop-list { 891 container next-hop-list { 892 description 893 "Container for multiple next hops."; 894 list next-hop { 895 description 896 "An entry of a next-hop list. 898 Modules for address families MUST augment this list 899 with a leaf containing a next-hop address of that 900 address family."; 902 leaf outgoing-interface { 903 type if:interface-ref; 904 description 905 "Name of the outgoing interface."; 906 } 907 } 908 } 909 } 910 } 911 } 913 grouping route-metadata { 914 description 915 "Common route metadata."; 916 leaf source-protocol { 917 type identityref { 918 base rt:routing-protocol; 919 } 920 mandatory "true"; 921 description 922 "Type of the routing protocol from which the route 923 originated."; 924 } 925 leaf active { 926 type empty; 927 description 928 "Presence of this leaf indicates that the route is preferred 929 among all routes in the same RIB that have the same 930 destination prefix."; 931 } 932 leaf last-updated { 933 type yang:date-and-time; 934 description 935 "Time stamp of the last modification of the route. If the 936 route was never modified, it is the time when the route was 937 inserted into the RIB."; 938 } 939 } 941 /* Configuration Data */ 943 container routing { 944 description 945 "Configuration parameters for the routing subsystem."; 946 uses router-id { 947 if-feature "router-id"; 948 description 949 "Configuration of the global router ID. Routing protocols 950 that use router ID can use this parameter or override it 951 with another value."; 952 } 953 container interfaces { 954 config "false"; 955 description 956 "Network-layer interfaces used for routing."; 957 leaf-list interface { 958 type if:interface-ref; 959 description 960 "Each entry is a reference to the name of a configured 961 network-layer interface."; 962 } 963 } 964 container control-plane-protocols { 965 description 966 "Configuration of control-plane protocol instances."; 967 list control-plane-protocol { 968 key "type name"; 969 description 970 "Each entry contains configuration of a control-plane 971 protocol instance."; 972 leaf type { 973 type identityref { 974 base rt:control-plane-protocol; 975 } 976 description 977 "Type of the control-plane protocol - an identity derived 978 from the 'control-plane-protocol' base identity."; 979 } 980 leaf name { 981 type string; 982 description 983 "An arbitrary name of the control-plane protocol 984 instance."; 985 } 986 leaf description { 987 type string; 988 description 989 "Textual description of the control-plane protocol 990 instance."; 991 } 992 container static-routes { 993 when "derived-from-or-self(../type, 'rt:static')" { 994 description 995 "This container is only valid for the 'static' routing 996 protocol."; 997 } 998 description 999 "Configuration of the 'static' pseudo-protocol. 1001 Address-family-specific modules augment this node with 1002 their lists of routes."; 1003 } 1004 } 1005 } 1006 container ribs { 1007 description 1008 "Configuration of RIBs."; 1009 list rib { 1010 key "name"; 1011 description 1012 "Each entry contains configuration for a RIB identified by 1013 the 'name' key. 1015 Entries having the same key as a system-controlled entry 1016 of the list /routing/ribs/rib are used for 1017 configuring parameters of that entry. Other entries 1018 define additional user-controlled RIBs."; 1019 leaf name { 1020 type string; 1021 description 1022 "The name of the RIB. 1024 For system-controlled entries, the value of this leaf 1025 must be the same as the name of the corresponding entry 1026 in state data. 1028 For user-controlled entries, an arbitrary name can be 1029 used."; 1030 } 1031 uses address-family { 1032 description 1033 "The address family of the system-controlled RIB."; 1034 } 1036 leaf default-rib { 1037 if-feature "multiple-ribs"; 1038 type boolean; 1039 default "true"; 1040 config "false"; 1041 description 1042 "This flag has the value of 'true' if and only if the RIB 1043 is the default RIB for the given address family. 1045 By default, control-plane protocols place their routes 1046 in the default RIBs."; 1047 } 1048 container routes { 1049 config "false"; 1050 description 1051 "Current content of the RIB."; 1052 list route { 1053 description 1054 "A RIB route entry. This data node MUST be augmented 1055 with information specific for routes of each address 1056 family."; 1057 leaf route-preference { 1058 type route-preference; 1059 description 1060 "This route attribute, also known as administrative 1061 distance, allows for selecting the preferred route 1062 among routes with the same destination prefix. A 1063 smaller value means a more preferred route."; 1064 } 1065 container next-hop { 1066 description 1067 "Route's next-hop attribute."; 1068 uses next-hop-state-content; 1069 } 1070 uses route-metadata; 1071 } 1072 } 1073 action active-route { 1074 description 1075 "Return the active RIB route that is used for the 1076 destination address. 1078 Address-family-specific modules MUST augment input 1079 parameters with a leaf named 'destination-address'."; 1080 output { 1081 container route { 1082 description 1083 "The active RIB route for the specified destination. 1085 If no route exists in the RIB for the destination 1086 address, no output is returned. 1088 Address-family-specific modules MUST augment this 1089 container with appropriate route contents."; 1090 container next-hop { 1091 description 1092 "Route's next-hop attribute."; 1093 uses next-hop-state-content; 1095 } 1096 uses route-metadata; 1097 } 1098 } 1099 } 1100 leaf description { 1101 type string; 1102 description 1103 "Textual description of the RIB."; 1104 } 1105 } 1106 } 1107 } 1109 /* Obsolete State Data */ 1111 container routing-state { 1112 config false; 1113 status obsolete; 1114 description 1115 "State data of the routing subsystem."; 1116 uses router-id { 1117 status obsolete; 1118 description 1119 "Global router ID. 1121 It may be either configured or assigned algorithmically by 1122 the implementation."; 1123 } 1124 container interfaces { 1125 status obsolete; 1126 description 1127 "Network-layer interfaces used for routing."; 1128 leaf-list interface { 1129 type if:interface-state-ref; 1130 status obsolete; 1131 description 1132 "Each entry is a reference to the name of a configured 1133 network-layer interface."; 1134 } 1135 } 1136 container control-plane-protocols { 1137 status obsolete; 1138 description 1139 "Container for the list of routing protocol instances."; 1140 list control-plane-protocol { 1141 key "type name"; 1142 status obsolete; 1143 description 1144 "State data of a control-plane protocol instance. 1146 An implementation MUST provide exactly one 1147 system-controlled instance of the 'direct' 1148 pseudo-protocol. Instances of other control-plane 1149 protocols MAY be created by configuration."; 1150 leaf type { 1151 type identityref { 1152 base rt:control-plane-protocol; 1153 } 1154 status obsolete; 1155 description 1156 "Type of the control-plane protocol."; 1157 } 1158 leaf name { 1159 type string; 1160 status obsolete; 1161 description 1162 "The name of the control-plane protocol instance. 1164 For system-controlled instances this name is 1165 persistent, i.e., it SHOULD NOT change across 1166 reboots."; 1167 } 1168 } 1169 } 1170 container ribs { 1171 status obsolete; 1172 description 1173 "Container for RIBs."; 1174 list rib { 1175 key "name"; 1176 min-elements 1; 1177 status obsolete; 1178 description 1179 "Each entry represents a RIB identified by the 'name' 1180 key. All routes in a RIB MUST belong to the same address 1181 family. 1183 An implementation SHOULD provide one system-controlled 1184 default RIB for each supported address family."; 1185 leaf name { 1186 type string; 1187 status obsolete; 1188 description 1189 "The name of the RIB."; 1190 } 1191 uses address-family { 1192 status obsolete; 1193 description 1194 "The address family of the RIB."; 1195 } 1196 leaf default-rib { 1197 if-feature "multiple-ribs"; 1198 type boolean; 1199 default "true"; 1200 status obsolete; 1201 description 1202 "This flag has the value of 'true' if and only if the 1203 RIB is the default RIB for the given address family. 1205 By default, control-plane protocols place their routes 1206 in the default RIBs."; 1207 } 1208 container routes { 1209 status obsolete; 1210 description 1211 "Current content of the RIB."; 1212 list route { 1213 status obsolete; 1214 description 1215 "A RIB route entry. This data node MUST be augmented 1216 with information specific for routes of each address 1217 family."; 1218 leaf route-preference { 1219 type route-preference; 1220 status obsolete; 1221 description 1222 "This route attribute, also known as administrative 1223 distance, allows for selecting the preferred route 1224 among routes with the same destination prefix. A 1225 smaller value means a more preferred route."; 1226 } 1227 container next-hop { 1228 status obsolete; 1229 description 1230 "Route's next-hop attribute."; 1231 uses next-hop-state-content { 1232 status obsolete; 1233 description 1234 "Route's next-hop attribute operational state."; 1235 } 1236 } 1237 uses route-metadata { 1238 status obsolete; 1239 description 1240 "Route metadata."; 1241 } 1242 } 1243 } 1244 action active-route { 1245 status obsolete; 1246 description 1247 "Return the active RIB route that is used for the 1248 destination address. 1250 Address-family-specific modules MUST augment input 1251 parameters with a leaf named 'destination-address'."; 1252 output { 1253 container route { 1254 status obsolete; 1255 description 1256 "The active RIB route for the specified 1257 destination. 1259 If no route exists in the RIB for the destination 1260 address, no output is returned. 1262 Address-family-specific modules MUST augment this 1263 container with appropriate route contents."; 1264 container next-hop { 1265 status obsolete; 1266 description 1267 "Route's next-hop attribute."; 1268 uses next-hop-state-content { 1269 status obsolete; 1270 description 1271 "Active route state data."; 1272 } 1273 } 1274 uses route-metadata { 1275 status obsolete; 1276 description 1277 "Active route metadata."; 1278 } 1279 } 1280 } 1281 } 1282 } 1283 } 1284 } 1285 } 1286 1288 8. IPv4 Unicast Routing Management YANG Module 1290 file "ietf-ipv4-unicast-routing@2017-11-30.yang" 1291 module ietf-ipv4-unicast-routing { 1292 yang-version "1.1"; 1293 namespace 1294 "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1295 prefix "v4ur"; 1297 import ietf-routing { 1298 prefix "rt"; 1299 } 1301 import ietf-inet-types { 1302 prefix "inet"; 1303 } 1304 organization 1305 "IETF NETMOD - Networking Modeling Working Group"; 1306 contact 1307 "WG Web: 1308 WG List: 1310 Editor: Ladislav Lhotka 1311 1312 Acee Lindem 1313 1314 Yingzhen Qu 1315 "; 1317 description 1318 "This YANG module augments the 'ietf-routing' module with basic 1319 configuration and state data for IPv4 unicast routing. 1321 Copyright (c) 2017 IETF Trust and the persons 1322 identified as authors of the code. All rights reserved. 1324 Redistribution and use in source and binary forms, with or 1325 without modification, is permitted pursuant to, and subject 1326 to the license terms contained in, the Simplified BSD License 1327 set forth in Section 4.c of the IETF Trust's Legal Provisions 1328 Relating to IETF Documents 1329 (http://trustee.ietf.org/license-info). 1331 This version of this YANG module is part of RFC XXXX; see 1332 the RFC itself for full legal notices."; 1333 reference "RFC XXXX"; 1335 revision 2017-10-14 { 1336 description 1337 "Network Managment Datastore Architecture (NDMA) Revision"; 1338 reference 1339 "RFC XXXX: A YANG Data Model for Routing Management 1340 (NDMA Version)"; 1341 } 1343 revision 2016-11-04 { 1344 description 1345 "Initial revision."; 1346 reference 1347 "RFC 8022: A YANG Data Model for Routing Management"; 1348 } 1350 /* Identities */ 1352 identity ipv4-unicast { 1353 base rt:ipv4; 1354 description 1355 "This identity represents the IPv4 unicast address family."; 1356 } 1358 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { 1359 when "derived-from-or-self(../../rt:address-family, " 1360 + "'v4ur:ipv4-unicast')" { 1361 description 1362 "This augment is valid only for IPv4 unicast."; 1363 } 1364 description 1365 "This leaf augments an IPv4 unicast route."; 1366 leaf destination-prefix { 1367 type inet:ipv4-prefix; 1368 description 1369 "IPv4 destination prefix."; 1370 } 1371 } 1373 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" 1374 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1375 when "derived-from-or-self(../../../rt:address-family, " 1376 + "'v4ur:ipv4-unicast')" { 1377 description 1378 "This augment is valid only for IPv4 unicast."; 1379 } 1380 description 1381 "Augment 'simple-next-hop' case in IPv4 unicast routes."; 1382 leaf next-hop-address { 1383 type inet:ipv4-address; 1384 description 1385 "IPv4 address of the next hop."; 1386 } 1387 } 1389 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" 1390 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1391 + "rt:next-hop-list/rt:next-hop" { 1392 when "derived-from-or-self(../../../../../rt:address-family, " 1393 + "'v4ur:ipv4-unicast')" { 1394 description 1395 "This augment is valid only for IPv4 unicast."; 1396 } 1397 description 1398 "This leaf augments the 'next-hop-list' case of IPv4 unicast 1399 routes."; 1400 leaf address { 1401 type inet:ipv4-address; 1402 description 1403 "IPv4 address of the next-hop."; 1404 } 1405 } 1407 augment 1408 "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" { 1409 when "derived-from-or-self(../rt:address-family, " 1410 + "'v4ur:ipv4-unicast')" { 1411 description 1412 "This augment is valid only for IPv4 unicast RIBs."; 1413 } 1414 description 1415 "This augment adds the input parameter of the 'active-route' 1416 action."; 1417 leaf destination-address { 1418 type inet:ipv4-address; 1419 description 1420 "IPv4 destination address."; 1421 } 1422 } 1424 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1425 + "rt:output/rt:route" { 1426 when "derived-from-or-self(../../rt:address-family, " 1427 + "'v4ur:ipv4-unicast')" { 1428 description 1429 "This augment is valid only for IPv4 unicast."; 1430 } 1431 description 1432 "This augment adds the destination prefix to the reply of the 1433 'active-route' action."; 1434 leaf destination-prefix { 1435 type inet:ipv4-prefix; 1436 description 1437 "IPv4 destination prefix."; 1438 } 1439 } 1441 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1442 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1443 + "rt:simple-next-hop" { 1444 when "derived-from-or-self(../../../rt:address-family, " 1445 + "'v4ur:ipv4-unicast')" { 1446 description 1447 "This augment is valid only for IPv4 unicast."; 1448 } 1449 description 1450 "Augment 'simple-next-hop' case in the reply to the 1451 'active-route' action."; 1452 leaf next-hop-address { 1453 type inet:ipv4-address; 1454 description 1455 "IPv4 address of the next hop."; 1456 } 1457 } 1459 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1460 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1461 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1462 when "derived-from-or-self(../../../../../rt:address-family, " 1463 + "'v4ur:ipv4-unicast')" { 1464 description 1465 "This augment is valid only for IPv4 unicast."; 1466 } 1467 description 1468 "Augment 'next-hop-list' case in the reply to the 1469 'active-route' action."; 1470 leaf next-hop-address { 1471 type inet:ipv4-address; 1472 description 1473 "IPv4 address of the next hop."; 1474 } 1475 } 1477 augment "/rt:routing/rt:control-plane-protocols/" 1478 + "rt:control-plane-protocol/rt:static-routes" { 1479 description 1480 "This augment defines the configuration of the 'static' 1481 pseudo-protocol with data specific to IPv4 unicast."; 1482 container ipv4 { 1483 description 1484 "Configuration of a 'static' pseudo-protocol instance 1485 consists of a list of routes."; 1486 list route { 1487 key "destination-prefix"; 1488 description 1489 "A list of static routes."; 1490 leaf destination-prefix { 1491 type inet:ipv4-prefix; 1492 mandatory "true"; 1493 description 1494 "IPv4 destination prefix."; 1495 } 1496 leaf description { 1497 type string; 1498 description 1499 "Textual description of the route."; 1500 } 1501 container next-hop { 1502 description 1503 "Configuration of next-hop."; 1504 uses rt:next-hop-content { 1505 augment "next-hop-options/simple-next-hop" { 1506 description 1507 "Augment 'simple-next-hop' case in IPv4 static 1508 routes."; 1509 leaf next-hop-address { 1510 type inet:ipv4-address; 1511 description 1512 "IPv4 address of the next hop."; 1513 } 1514 } 1515 augment "next-hop-options/next-hop-list/next-hop-list/" 1516 + "next-hop" { 1517 description 1518 "Augment 'next-hop-list' case in IPv4 static 1519 routes."; 1520 leaf next-hop-address { 1521 type inet:ipv4-address; 1522 description 1523 "IPv4 address of the next hop."; 1524 } 1525 } 1526 } 1527 } 1529 } 1530 } 1531 } 1533 /* Obsolete State Data */ 1535 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1536 when "derived-from-or-self(../../rt:address-family, " 1537 + "'v4ur:ipv4-unicast')" { 1538 description 1539 "This augment is valid only for IPv4 unicast."; 1540 } 1541 status obsolete; 1542 description 1543 "This leaf augments an IPv4 unicast route."; 1544 leaf destination-prefix { 1545 type inet:ipv4-prefix; 1546 status obsolete; 1547 description 1548 "IPv4 destination prefix."; 1549 } 1550 } 1551 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1552 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1553 when "derived-from-or-self( 1554 ../../../rt:address-family, 'v4ur:ipv4-unicast')" { 1555 description 1556 "This augment is valid only for IPv4 unicast."; 1557 } 1558 status obsolete; 1559 description 1560 "Augment 'simple-next-hop' case in IPv4 unicast routes."; 1561 leaf next-hop-address { 1562 type inet:ipv4-address; 1563 status obsolete; 1564 description 1565 "IPv4 address of the next hop."; 1566 } 1567 } 1568 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1569 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1570 + "rt:next-hop-list/rt:next-hop" { 1571 when "derived-from-or-self(../../../../../rt:address-family, 1572 'v4ur:ipv4-unicast')" { 1573 description 1574 "This augment is valid only for IPv4 unicast."; 1575 } 1576 status obsolete; 1577 description 1578 "This leaf augments the 'next-hop-list' case of IPv4 unicast 1579 routes."; 1580 leaf address { 1581 type inet:ipv4-address; 1582 status obsolete; 1583 description 1584 "IPv4 address of the next-hop."; 1585 } 1586 } 1587 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1588 + "rt:input" { 1589 when "derived-from-or-self(../rt:address-family, 1590 'v4ur:ipv4-unicast')" { 1591 description 1592 "This augment is valid only for IPv4 unicast RIBs."; 1593 } 1594 status obsolete; 1595 description 1596 "This augment adds the input parameter of the 'active-route' 1597 action."; 1598 leaf destination-address { 1599 type inet:ipv4-address; 1600 status obsolete; 1601 description 1602 "IPv4 destination address."; 1603 } 1604 } 1605 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1606 + "rt:output/rt:route" { 1607 when "derived-from-or-self(../../rt:address-family, 1608 'v4ur:ipv4-unicast')" { 1609 description 1610 "This augment is valid only for IPv4 unicast."; 1611 } 1612 status obsolete; 1613 description 1614 "This augment adds the destination prefix to the reply of the 1615 'active-route' action."; 1616 leaf destination-prefix { 1617 type inet:ipv4-prefix; 1618 status obsolete; 1619 description 1620 "IPv4 destination prefix."; 1621 } 1622 } 1623 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1624 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1625 + "rt:simple-next-hop" { 1626 when "derived-from-or-self(../../../rt:address-family, 1627 'v4ur:ipv4-unicast')" { 1628 description 1629 "This augment is valid only for IPv4 unicast."; 1630 } 1631 status obsolete; 1632 description 1633 "Augment 'simple-next-hop' case in the reply to the 1634 'active-route' action."; 1635 leaf next-hop-address { 1636 type inet:ipv4-address; 1637 status obsolete; 1638 description 1639 "IPv4 address of the next hop."; 1640 } 1641 } 1642 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1643 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1644 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1645 when "derived-from-or-self(../../../../../rt:address-family, 1646 'v4ur:ipv4-unicast')" { 1647 description 1648 "This augment is valid only for IPv4 unicast."; 1649 } 1650 status obsolete; 1651 description 1652 "Augment 'next-hop-list' case in the reply to the 1653 'active-route' action."; 1654 leaf next-hop-address { 1655 type inet:ipv4-address; 1656 status obsolete; 1657 description 1658 "IPv4 address of the next hop."; 1659 } 1660 } 1661 } 1662 1664 9. IPv6 Unicast Routing Management YANG Module 1666 file "ietf-ipv6-unicast-routing@2017-11-30.yang" 1667 module ietf-ipv6-unicast-routing { 1668 yang-version "1.1"; 1669 namespace 1670 "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1671 prefix "v6ur"; 1672 import ietf-routing { 1673 prefix "rt"; 1674 } 1676 import ietf-inet-types { 1677 prefix "inet"; 1678 } 1680 include ietf-ipv6-router-advertisements { 1681 revision-date 2017-10-14; 1682 } 1684 organization 1685 "IETF NETMOD - Networking Modeling Working Group"; 1686 contact 1687 "WG Web: 1688 WG List: 1690 Editor: Ladislav Lhotka 1691 1692 Acee Lindem 1693 1694 Yingzhen Qu 1695 "; 1697 description 1698 "This YANG module augments the 'ietf-routing' module with basic 1699 configuration and state data for IPv6 unicast routing. 1701 Copyright (c) 2017 IETF Trust and the persons 1702 identified as authors of the code. All rights reserved. 1704 Redistribution and use in source and binary forms, with or 1705 without modification, is permitted pursuant to, and subject 1706 to the license terms contained in, the Simplified BSD License 1707 set forth in Section 4.c of the IETF Trust's Legal Provisions 1708 Relating to IETF Documents 1709 (http://trustee.ietf.org/license-info). 1711 This version of this YANG module is part of RFC XXXX; see 1712 the RFC itself for full legal notices."; 1713 reference "RFC XXXX"; 1715 revision 2017-10-14 { 1716 description 1717 "Network Managment Datastore Architecture (NDMA) revision"; 1718 reference 1719 "RFC XXXX: A YANG Data Model for Routing Management 1720 (NDMA Version)"; 1721 } 1723 /* Identities */ 1725 revision 2016-11-04 { 1726 description 1727 "Initial revision."; 1728 reference 1729 "RFC 8022: A YANG Data Model for Routing Management"; 1730 } 1732 identity ipv6-unicast { 1733 base rt:ipv6; 1734 description 1735 "This identity represents the IPv6 unicast address family."; 1736 } 1738 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { 1739 when "derived-from-or-self(../../rt:address-family, " 1740 + "'v6ur:ipv6-unicast')" { 1741 description 1742 "This augment is valid only for IPv6 unicast."; 1743 } 1744 description 1745 "This leaf augments an IPv6 unicast route."; 1746 leaf destination-prefix { 1747 type inet:ipv6-prefix; 1748 description 1749 "IPv6 destination prefix."; 1750 } 1751 } 1753 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" 1754 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1755 when "derived-from-or-self(../../../rt:address-family, " 1756 + "'v6ur:ipv6-unicast')" { 1757 description 1758 "This augment is valid only for IPv6 unicast."; 1759 } 1760 description 1761 "Augment 'simple-next-hop' case in IPv6 unicast routes."; 1762 leaf next-hop-address { 1763 type inet:ipv6-address; 1764 description 1765 "IPv6 address of the next hop."; 1766 } 1767 } 1768 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" 1769 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1770 + "rt:next-hop-list/rt:next-hop" { 1771 when "derived-from-or-self(../../../../../rt:address-family, " 1772 + "'v6ur:ipv6-unicast')" { 1773 description 1774 "This augment is valid only for IPv6 unicast."; 1775 } 1776 description 1777 "This leaf augments the 'next-hop-list' case of IPv6 unicast 1778 routes."; 1779 leaf address { 1780 type inet:ipv6-address; 1781 description 1782 "IPv6 address of the next hop."; 1783 } 1784 } 1786 augment 1787 "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" { 1788 when "derived-from-or-self(../rt:address-family, " 1789 + "'v6ur:ipv6-unicast')" { 1790 description 1791 "This augment is valid only for IPv6 unicast RIBs."; 1792 } 1793 description 1794 "This augment adds the input parameter of the 'active-route' 1795 action."; 1796 leaf destination-address { 1797 type inet:ipv6-address; 1798 description 1799 "IPv6 destination address."; 1800 } 1801 } 1803 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1804 + "rt:output/rt:route" { 1805 when "derived-from-or-self(../../rt:address-family, " 1806 + "'v6ur:ipv6-unicast')" { 1807 description 1808 "This augment is valid only for IPv6 unicast."; 1809 } 1810 description 1811 "This augment adds the destination prefix to the reply of the 1812 'active-route' action."; 1813 leaf destination-prefix { 1814 type inet:ipv6-prefix; 1815 description 1816 "IPv6 destination prefix."; 1817 } 1818 } 1820 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1821 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1822 + "rt:simple-next-hop" { 1823 when "derived-from-or-self(../../../rt:address-family, " 1824 + "'v6ur:ipv6-unicast')" { 1825 description 1826 "This augment is valid only for IPv6 unicast."; 1827 } 1828 description 1829 "Augment 'simple-next-hop' case in the reply to the 1830 'active-route' action."; 1831 leaf next-hop-address { 1832 type inet:ipv6-address; 1833 description 1834 "IPv6 address of the next hop."; 1835 } 1836 } 1838 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1839 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1840 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1841 when "derived-from-or-self(../../../../../rt:address-family, " 1842 + "'v6ur:ipv6-unicast')" { 1843 description 1844 "This augment is valid only for IPv6 unicast."; 1845 } 1846 description 1847 "Augment 'next-hop-list' case in the reply to the 1848 'active-route' action."; 1849 leaf next-hop-address { 1850 type inet:ipv6-address; 1851 description 1852 "IPv6 address of the next hop."; 1853 } 1854 } 1856 /* Configuration data */ 1858 augment "/rt:routing/rt:control-plane-protocols/" 1859 + "rt:control-plane-protocol/rt:static-routes" { 1860 description 1861 "This augment defines the configuration of the 'static' 1862 pseudo-protocol with data specific to IPv6 unicast."; 1863 container ipv6 { 1864 description 1865 "Configuration of a 'static' pseudo-protocol instance 1866 consists of a list of routes."; 1867 list route { 1868 key "destination-prefix"; 1869 description 1870 "A list of static routes."; 1871 leaf destination-prefix { 1872 type inet:ipv6-prefix; 1873 mandatory "true"; 1874 description 1875 "IPv6 destination prefix."; 1876 } 1877 leaf description { 1878 type string; 1879 description 1880 "Textual description of the route."; 1881 } 1882 container next-hop { 1883 description 1884 "Configuration of next-hop."; 1885 uses rt:next-hop-content { 1886 augment "next-hop-options/simple-next-hop" { 1887 description 1888 "Augment 'simple-next-hop' case in IPv6 static 1889 routes."; 1890 leaf next-hop-address { 1891 type inet:ipv6-address; 1892 description 1893 "IPv6 address of the next hop."; 1894 } 1895 } 1896 augment "next-hop-options/next-hop-list/next-hop-list/" 1897 + "next-hop" { 1898 description 1899 "Augment 'next-hop-list' case in IPv6 static 1900 routes."; 1901 leaf next-hop-address { 1902 type inet:ipv6-address; 1903 description 1904 "IPv6 address of the next hop."; 1905 } 1906 } 1907 } 1908 } 1909 } 1910 } 1911 } 1912 /* Obsolete State Data */ 1914 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1915 when "derived-from-or-self(../../rt:address-family, 1916 'v6ur:ipv6-unicast')" { 1917 description 1918 "This augment is valid only for IPv6 unicast."; 1919 } 1920 status obsolete; 1921 description 1922 "This leaf augments an IPv6 unicast route."; 1923 leaf destination-prefix { 1924 type inet:ipv6-prefix; 1925 status obsolete; 1926 description 1927 "IPv6 destination prefix."; 1928 } 1929 } 1930 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1931 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1932 when "derived-from-or-self(../../../rt:address-family, 1933 'v6ur:ipv6-unicast')" { 1934 description 1935 "This augment is valid only for IPv6 unicast."; 1936 } 1937 status obsolete; 1938 description 1939 "Augment 'simple-next-hop' case in IPv6 unicast routes."; 1940 leaf next-hop-address { 1941 type inet:ipv6-address; 1942 status obsolete; 1943 description 1944 "IPv6 address of the next hop."; 1945 } 1946 } 1947 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1948 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1949 + "rt:next-hop-list/rt:next-hop" { 1950 when "derived-from-or-self(../../../../../rt:address-family, 1951 'v6ur:ipv6-unicast')" { 1952 description 1953 "This augment is valid only for IPv6 unicast."; 1954 } 1955 status obsolete; 1956 description 1957 "This leaf augments the 'next-hop-list' case of IPv6 unicast 1958 routes."; 1959 leaf address { 1960 type inet:ipv6-address; 1961 status obsolete; 1962 description 1963 "IPv6 address of the next hop."; 1964 } 1965 } 1966 augment "/rt:routing-state/rt:ribs/rt:rib/" 1967 + "rt:active-route/rt:input" { 1968 when "derived-from-or-self(../rt:address-family, 1969 'v6ur:ipv6-unicast')" { 1970 description 1971 "This augment is valid only for IPv6 unicast RIBs."; 1972 } 1973 status obsolete; 1974 description 1975 "This augment adds the input parameter of the 'active-route' 1976 action."; 1977 leaf destination-address { 1978 type inet:ipv6-address; 1979 status obsolete; 1980 description 1981 "IPv6 destination address."; 1982 } 1983 } 1984 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1985 + "rt:output/rt:route" { 1986 when "derived-from-or-self(../../rt:address-family, 1987 'v6ur:ipv6-unicast')" { 1988 description 1989 "This augment is valid only for IPv6 unicast."; 1990 } 1991 status obsolete; 1992 description 1993 "This augment adds the destination prefix to the reply of the 1994 'active-route' action."; 1995 leaf destination-prefix { 1996 type inet:ipv6-prefix; 1997 status obsolete; 1998 description 1999 "IPv6 destination prefix."; 2000 } 2001 } 2002 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 2003 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 2004 + "rt:simple-next-hop" { 2005 when "derived-from-or-self(../../../rt:address-family, 2006 'v6ur:ipv6-unicast')" { 2007 description 2008 "This augment is valid only for IPv6 unicast."; 2009 } 2010 status obsolete; 2011 description 2012 "Augment 'simple-next-hop' case in the reply to the 2013 'active-route' action."; 2014 leaf next-hop-address { 2015 type inet:ipv6-address; 2016 status obsolete; 2017 description 2018 "IPv6 address of the next hop."; 2019 } 2020 } 2021 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 2022 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 2023 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 2024 when "derived-from-or-self(../../../../../rt:address-family, 2025 'v6ur:ipv6-unicast')" { 2026 description 2027 "This augment is valid only for IPv6 unicast."; 2028 } 2029 status obsolete; 2030 description 2031 "Augment 'next-hop-list' case in the reply to the 2032 'active-route' action."; 2033 leaf next-hop-address { 2034 type inet:ipv6-address; 2035 status obsolete; 2036 description 2037 "IPv6 address of the next hop."; 2038 } 2039 } 2040 } 2041 2043 9.1. IPv6 Router Advertisements Submodule 2045 file "ietf-ipv6-router-advertisements@2017-11-30.yang" 2046 submodule ietf-ipv6-router-advertisements { 2047 yang-version "1.1"; 2049 belongs-to ietf-ipv6-unicast-routing { 2050 prefix "v6ur"; 2051 } 2053 import ietf-inet-types { 2054 prefix "inet"; 2055 } 2056 import ietf-interfaces { 2057 prefix "if"; 2058 } 2060 import ietf-ip { 2061 prefix "ip"; 2062 } 2064 organization 2065 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 2066 contact 2067 "WG Web: 2068 WG List: 2070 WG Chair: Lou Berger 2071 2073 WG Chair: Kent Watsen 2074 2076 Editor: Ladislav Lhotka 2077 2079 Editor: Acee Lindem 2080 2082 Editor: Yingzhen Qu 2083 "; 2085 description 2086 "This YANG module augments the 'ietf-ip' module with 2087 configuration and state data of IPv6 router advertisements. 2089 Copyright (c) 2017 IETF Trust and the persons identified as 2090 authors of the code. All rights reserved. 2092 Redistribution and use in source and binary forms, with or 2093 without modification, is permitted pursuant to, and subject 2094 to the license terms contained in, the Simplified BSD License 2095 set forth in Section 4.c of the IETF Trust's Legal Provisions 2096 Relating to IETF Documents 2097 (http://trustee.ietf.org/license-info). 2099 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 2100 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 2101 'OPTIONAL' in the module text are to be interpreted as 2102 described in RFC 2119. 2104 This version of this YANG module is part of RFC 8022; 2105 see the RFC itself for full legal notices."; 2107 reference 2108 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)."; 2110 revision 2017-10-14 { 2111 description 2112 "Network Managment Datastore Architecture (NDMA) Revision"; 2113 reference 2114 "RFC XXXX: A YANG Data Model for Routing Management 2115 (NDMA Version)"; 2116 } 2118 revision 2016-11-04 { 2119 description 2120 "Initial revision."; 2121 reference 2122 "RFC 8022: A YANG Data Model for Routing Management"; 2123 } 2125 augment "/if:interfaces/if:interface/ip:ipv6" { 2126 description 2127 "Augment interface configuration with parameters of IPv6 2128 router advertisements."; 2129 container ipv6-router-advertisements { 2130 description 2131 "Configuration of IPv6 Router Advertisements."; 2132 leaf send-advertisements { 2133 type boolean; 2134 default "false"; 2135 description 2136 "A flag indicating whether or not the router sends 2137 periodic Router Advertisements and responds to 2138 Router Solicitations."; 2139 reference 2140 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2141 AdvSendAdvertisements."; 2142 } 2143 leaf max-rtr-adv-interval { 2144 type uint16 { 2145 range "4..1800"; 2146 } 2147 units "seconds"; 2148 default "600"; 2149 description 2150 "The maximum time allowed between sending unsolicited 2151 multicast Router Advertisements from the interface."; 2153 reference 2154 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2155 MaxRtrAdvInterval."; 2156 } 2157 leaf min-rtr-adv-interval { 2158 type uint16 { 2159 range "3..1350"; 2160 } 2161 units "seconds"; 2162 must ". <= 0.75 * ../max-rtr-adv-interval" { 2163 description 2164 "The value MUST NOT be greater than 75% of 2165 'max-rtr-adv-interval'."; 2166 } 2167 description 2168 "The minimum time allowed between sending unsolicited 2169 multicast Router Advertisements from the interface. 2171 The default value to be used operationally if this 2172 leaf is not configured is determined as follows: 2174 - if max-rtr-adv-interval >= 9 seconds, the default 2175 value is 0.33 * max-rtr-adv-interval; 2177 - otherwise, it is 0.75 * max-rtr-adv-interval."; 2178 reference 2179 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2180 MinRtrAdvInterval."; 2181 } 2182 leaf managed-flag { 2183 type boolean; 2184 default "false"; 2185 description 2186 "The value to be placed in the 'Managed address 2187 configuration' flag field in the Router 2188 Advertisement."; 2189 reference 2190 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2191 AdvManagedFlag."; 2192 } 2193 leaf other-config-flag { 2194 type boolean; 2195 default "false"; 2196 description 2197 "The value to be placed in the 'Other configuration' 2198 flag field in the Router Advertisement."; 2199 reference 2200 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2201 AdvOtherConfigFlag."; 2202 } 2203 leaf link-mtu { 2204 type uint32; 2205 default "0"; 2206 description 2207 "The value to be placed in MTU options sent by the 2208 router. A value of zero indicates that no MTU options 2209 are sent."; 2210 reference 2211 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2212 AdvLinkMTU."; 2213 } 2214 leaf reachable-time { 2215 type uint32 { 2216 range "0..3600000"; 2217 } 2218 units "milliseconds"; 2219 default "0"; 2220 description 2221 "The value to be placed in the Reachable Time field in 2222 the Router Advertisement messages sent by the router. 2223 A value of zero means unspecified (by this router)."; 2224 reference 2225 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2226 AdvReachableTime."; 2227 } 2228 leaf retrans-timer { 2229 type uint32; 2230 units "milliseconds"; 2231 default "0"; 2232 description 2233 "The value to be placed in the Retrans Timer field in 2234 the Router Advertisement messages sent by the router. 2235 A value of zero means unspecified (by this router)."; 2236 reference 2237 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2238 AdvRetransTimer."; 2239 } 2240 leaf cur-hop-limit { 2241 type uint8; 2242 description 2243 "The value to be placed in the Cur Hop Limit field in 2244 the Router Advertisement messages sent by the router. 2245 A value of zero means unspecified (by this router). 2247 If this parameter is not configured, the device SHOULD 2248 use the value specified in IANA Assigned Numbers that 2249 was in effect at the time of implementation."; 2250 reference 2251 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2252 AdvCurHopLimit. 2254 IANA: IP Parameters, 2255 http://www.iana.org/assignments/ip-parameters"; 2256 } 2257 leaf default-lifetime { 2258 type uint16 { 2259 range "0..9000"; 2260 } 2261 units "seconds"; 2262 description 2263 "The value to be placed in the Router Lifetime field of 2264 Router Advertisements sent from the interface, in 2265 seconds. It MUST be either zero or between 2266 max-rtr-adv-interval and 9000 seconds. A value of zero 2267 default indicates that the router is not to be used as 2268 a router. These limits may be overridden by specific 2269 documents that describe how IPv6 operates over 2270 different link layers. 2272 If this parameter is not configured, the device SHOULD 2273 use a value of 3 * max-rtr-adv-interval."; 2274 reference 2275 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2276 AdvDefaultLifeTime."; 2277 } 2278 container prefix-list { 2279 description 2280 "Configuration of prefixes to be placed in Prefix 2281 Information options in Router Advertisement messages 2282 sent from the interface. 2284 Prefixes that are advertised by default but do not 2285 have their entries in the child 'prefix' list are 2286 advertised with the default values of all parameters. 2288 The link-local prefix SHOULD NOT be included in the 2289 list of advertised prefixes."; 2290 reference 2291 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2292 AdvPrefixList."; 2293 list prefix { 2294 key "prefix-spec"; 2295 description 2296 "Configuration of an advertised prefix entry."; 2298 leaf prefix-spec { 2299 type inet:ipv6-prefix; 2300 description 2301 "IPv6 address prefix."; 2302 } 2303 choice control-adv-prefixes { 2304 default "advertise"; 2305 description 2306 "Either the prefix is explicitly removed from the 2307 set of advertised prefixes, or the parameters with 2308 which it is advertised are specified (default 2309 case)."; 2310 leaf no-advertise { 2311 type empty; 2312 description 2313 "The prefix will not be advertised. 2315 This can be used for removing the prefix from 2316 the default set of advertised prefixes."; 2317 } 2318 case advertise { 2319 leaf valid-lifetime { 2320 type uint32; 2321 units "seconds"; 2322 default "2592000"; 2323 description 2324 "The value to be placed in the Valid Lifetime 2325 in the Prefix Information option. The 2326 designated value of all 1's (0xffffffff) 2327 represents infinity."; 2328 reference 2329 "RFC 4861: Neighbor Discovery for IP version 6 2330 (IPv6) - AdvValidLifetime."; 2331 } 2332 leaf on-link-flag { 2333 type boolean; 2334 default "true"; 2335 description 2336 "The value to be placed in the on-link flag 2337 ('L-bit') field in the Prefix Information 2338 option."; 2339 reference 2340 "RFC 4861: Neighbor Discovery for IP version 6 2341 (IPv6) - AdvOnLinkFlag."; 2342 } 2343 leaf preferred-lifetime { 2344 type uint32; 2345 units "seconds"; 2346 must ". <= ../valid-lifetime" { 2347 description 2348 "This value MUST NOT be greater than 2349 valid-lifetime."; 2350 } 2351 default "604800"; 2352 description 2353 "The value to be placed in the Preferred 2354 Lifetime in the Prefix Information option. 2355 The designated value of all 1's (0xffffffff) 2356 represents infinity."; 2357 reference 2358 "RFC 4861: Neighbor Discovery for IP version 6 2359 (IPv6) - AdvPreferredLifetime."; 2360 } 2361 leaf autonomous-flag { 2362 type boolean; 2363 default "true"; 2364 description 2365 "The value to be placed in the Autonomous Flag 2366 field in the Prefix Information option."; 2367 reference 2368 "RFC 4861: Neighbor Discovery for IP version 6 2369 (IPv6) - AdvAutonomousFlag."; 2370 } 2371 } 2372 } 2373 } 2374 } 2375 } 2376 } 2378 /* Obsolete State Data */ 2380 augment "/if:interfaces-state/if:interface/ip:ipv6" { 2381 status obsolete; 2382 description 2383 "Augment interface state data with parameters of IPv6 router 2384 advertisements."; 2385 container ipv6-router-advertisements { 2386 status obsolete; 2387 description 2388 "Parameters of IPv6 Router Advertisements."; 2389 leaf send-advertisements { 2390 type boolean; 2391 status obsolete; 2392 description 2393 "A flag indicating whether or not the router sends periodic 2394 Router Advertisements and responds to Router 2395 Solicitations."; 2396 } 2397 leaf max-rtr-adv-interval { 2398 type uint16 { 2399 range "4..1800"; 2400 } 2401 units "seconds"; 2402 status obsolete; 2403 description 2404 "The maximum time allowed between sending unsolicited 2405 multicast Router Advertisements from the interface."; 2406 } 2407 leaf min-rtr-adv-interval { 2408 type uint16 { 2409 range "3..1350"; 2410 } 2411 units "seconds"; 2412 status obsolete; 2413 description 2414 "The minimum time allowed between sending unsolicited 2415 multicast Router Advertisements from the interface."; 2416 } 2417 leaf managed-flag { 2418 type boolean; 2419 status obsolete; 2420 description 2421 "The value that is placed in the 'Managed address 2422 configuration' flag field in the Router Advertisement."; 2423 } 2424 leaf other-config-flag { 2425 type boolean; 2426 status obsolete; 2427 description 2428 "The value that is placed in the 'Other configuration' flag 2429 field in the Router Advertisement."; 2430 } 2431 leaf link-mtu { 2432 type uint32; 2433 status obsolete; 2434 description 2435 "The value that is placed in MTU options sent by the 2436 router. A value of zero indicates that no MTU options are 2437 sent."; 2438 } 2439 leaf reachable-time { 2440 type uint32 { 2441 range "0..3600000"; 2443 } 2444 units "milliseconds"; 2445 status obsolete; 2446 description 2447 "The value that is placed in the Reachable Time field in 2448 the Router Advertisement messages sent by the router. A 2449 value of zero means unspecified (by this router)."; 2450 } 2451 leaf retrans-timer { 2452 type uint32; 2453 units "milliseconds"; 2454 status obsolete; 2455 description 2456 "The value that is placed in the Retrans Timer field in the 2457 Router Advertisement messages sent by the router. A value 2458 of zero means unspecified (by this router)."; 2459 } 2460 leaf cur-hop-limit { 2461 type uint8; 2462 status obsolete; 2463 description 2464 "The value that is placed in the Cur Hop Limit field in the 2465 Router Advertisement messages sent by the router. A value 2466 of zero means unspecified (by this router)."; 2467 } 2468 leaf default-lifetime { 2469 type uint16 { 2470 range "0..9000"; 2471 } 2472 units "seconds"; 2473 status obsolete; 2474 description 2475 "The value that is placed in the Router Lifetime field of 2476 Router Advertisements sent from the interface, in seconds. 2477 A value of zero indicates that the router is not to be 2478 used as a default router."; 2479 } 2480 container prefix-list { 2481 status obsolete; 2482 description 2483 "A list of prefixes that are placed in Prefix Information 2484 options in Router Advertisement messages sent from the 2485 interface. 2487 By default, these are all prefixes that the router 2488 advertises via routing protocols as being on-link for the 2489 interface from which the advertisement is sent."; 2490 list prefix { 2491 key "prefix-spec"; 2492 status obsolete; 2493 description 2494 "Advertised prefix entry and its parameters."; 2495 leaf prefix-spec { 2496 type inet:ipv6-prefix; 2497 status obsolete; 2498 description 2499 "IPv6 address prefix."; 2500 } 2501 leaf valid-lifetime { 2502 type uint32; 2503 units "seconds"; 2504 status obsolete; 2505 description 2506 "The value that is placed in the Valid Lifetime in the 2507 Prefix Information option. The designated value of 2508 all 1's (0xffffffff) represents infinity. 2510 An implementation SHOULD keep this value constant in 2511 consecutive advertisements except when it is 2512 explicitly changed in configuration."; 2513 } 2514 leaf on-link-flag { 2515 type boolean; 2516 status obsolete; 2517 description 2518 "The value that is placed in the on-link flag ('L-bit') 2519 field in the Prefix Information option."; 2520 } 2521 leaf preferred-lifetime { 2522 type uint32; 2523 units "seconds"; 2524 status obsolete; 2525 description 2526 "The value that is placed in the Preferred Lifetime in 2527 the Prefix Information option, in seconds. The 2528 designated value of all 1's (0xffffffff) represents 2529 infinity. 2531 An implementation SHOULD keep this value constant in 2532 consecutive advertisements except when it is 2533 explicitly changed in configuration."; 2534 } 2535 leaf autonomous-flag { 2536 type boolean; 2537 status obsolete; 2538 description 2539 "The value that is placed in the Autonomous Flag field 2540 in the Prefix Information option."; 2541 } 2542 } 2543 } 2544 } 2545 } 2546 } 2547 2549 10. IANA Considerations 2551 [RFC8022] registered the following namespace URIs in the "IETF XML 2552 Registry" [RFC3688]: 2554 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2555 Registrant Contact: The IESG. 2556 XML: N/A; the requested URI is an XML namespace. 2558 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2559 Registrant Contact: The IESG. 2560 XML: N/A; the requested URI is an XML namespace. 2562 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2563 Registrant Contact: The IESG. 2564 XML: N/A; the requested URI is an XML namespace. 2566 [RFC8022] registered the following YANG modules in the "YANG Module 2567 Names" registry [RFC6020]: 2569 Name: ietf-routing 2570 Namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2571 Prefix: rt 2572 Reference: RFC 8022 2574 Name: ietf-ipv4-unicast-routing 2575 Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2576 Prefix: v4ur 2577 Reference: RFC 8022 2579 Name: ietf-ipv6-unicast-routing 2580 Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2581 Prefix: v6ur 2582 Reference: RFC 8022 2584 This document registers the following YANG submodule in the "YANG 2585 Module Names" registry [RFC6020]: 2587 Name: ietf-ipv6-router-advertisements 2588 Module: ietf-ipv6-unicast-routing 2589 Reference: RFC 8022 2591 11. Security Considerations 2593 The YANG module defined in this memo is designed to be accessed via 2594 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 2595 secure transport layer and the mandatory-to-implement secure 2596 transport is SSH [RFC6242]. 2598 There are a number of data nodes defined in this YANG module which 2599 are writable/creatable/deletable (i.e., config true, which is the 2600 default). These data nodes may be considered sensitive or vulnerable 2601 in some network environments. Write operations (e.g., edit-config) 2602 to these data nodes without proper protection can have a negative 2603 effect on network operations. These are the subtrees and data nodes 2604 and their sensitivity/vulnerability: 2606 /routing/control-plane-protocols/control-plane-protocol: This list 2607 specifies the control-plane protocols configured on a device. 2609 /routing/ribs/rib: This list specifies the RIBs configured for the 2610 device. 2612 Some of the readable data nodes in this YANG module may be considered 2613 sensitive or vulnerable in some network environments. It is thus 2614 important to control read access (e.g., via get, get-config, or 2615 notification) to these data nodes. These are the subtrees and data 2616 nodes and their sensitivity/vulnerability: 2618 /routing/control-plane-protocols/control-plane-protocol: This list 2619 specifies the control-plane protocols configured on a device. 2620 Refer to the control plane models for a list of sensitive 2621 information. 2623 /routing/ribs/rib: This list specifies the RIB and their contents 2624 for the device. Access to this information may disclose the 2625 network topology and or other information. 2627 12. References 2629 12.1. Normative References 2631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2632 Requirement Levels", BCP 14, RFC 2119, 2633 DOI 10.17487/RFC2119, March 1997, . 2636 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2637 DOI 10.17487/RFC3688, January 2004, . 2640 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2641 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2642 DOI 10.17487/RFC4861, September 2007, . 2645 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2646 the Network Configuration Protocol (NETCONF)", RFC 6020, 2647 DOI 10.17487/RFC6020, October 2010, . 2650 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2651 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2652 . 2654 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2655 and A. Bierman, Ed., "Network Configuration Protocol 2656 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2657 . 2659 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2660 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2661 . 2663 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2664 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2665 . 2667 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 2668 RFC 7277, DOI 10.17487/RFC7277, June 2014, 2669 . 2671 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2672 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2673 . 2675 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 2676 Management", RFC 8022, DOI 10.17487/RFC8022, November 2677 2016, . 2679 12.2. Informative References 2681 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2682 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 2683 January 2011, . 2685 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 2686 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 2687 . 2689 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2690 RFC 7951, DOI 10.17487/RFC7951, August 2016, 2691 . 2693 [I-D.ietf-netmod-revised-datastores] 2694 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2695 and R. Wilton, "Network Management Datastore 2696 Architecture", draft-ietf-netmod-revised-datastores-07 2697 (work in progress), November 2017. 2699 Appendix A. The Complete Data Trees 2701 This appendix presents the complete tree of the core routing data 2702 model. See Section 2.2 for an explanation of the symbols used. The 2703 data type of every leaf node is shown near the right end of the 2704 corresponding line. 2706 module: ietf-routing 2707 +--rw routing 2708 +--rw router-id? yang:dotted-quad 2709 +--ro interfaces 2710 | +--ro interface* if:interface-ref 2711 +--rw control-plane-protocols 2712 | +--rw control-plane-protocol* [type name] 2713 | +--rw type identityref 2714 | +--rw name string 2715 | +--rw description? string 2716 | +--rw static-routes 2717 | +--rw v4ur:ipv4 2718 | | +--rw v4ur:route* [destination-prefix] 2719 | | +--rw v4ur:destination-prefix inet:ipv4-prefix 2720 | | +--rw v4ur:description? string 2721 | | +--rw v4ur:next-hop 2722 | | +--rw (v4ur:next-hop-options) 2723 | | +--:(v4ur:simple-next-hop) 2724 | | | +--rw v4ur:outgoing-interface? 2725 | | | if:interface-ref 2726 | | | +--rw v4ur:next-hop-address? 2727 | | | inet:ipv4-address 2728 | | +--:(v4ur:special-next-hop) 2729 | | | +--rw v4ur:special-next-hop? enumeration 2730 | | +--:(v4ur:next-hop-list) 2731 | | +--rw v4ur:next-hop-list 2732 | | +--rw v4ur:next-hop* [index] 2733 | | +--rw v4ur:index string 2734 | | +--rw v4ur:outgoing-interface? 2735 | | if:interface-ref 2736 | | +--rw v4ur:next-hop-address? 2737 | | inet:ipv4-address 2738 | +--rw v6ur:ipv6 2739 | +--rw v6ur:route* [destination-prefix] 2740 | +--rw v6ur:destination-prefix inet:ipv6-prefix 2741 | +--rw v6ur:description? string 2742 | +--rw v6ur:next-hop 2743 | +--rw (v6ur:next-hop-options) 2744 | +--:(v6ur:simple-next-hop) 2745 | | +--rw v6ur:outgoing-interface? 2746 | | if:interface-ref 2747 | | +--rw v6ur:next-hop-address? 2748 | | inet:ipv6-address 2749 | +--:(v6ur:special-next-hop) 2750 | | +--rw v6ur:special-next-hop? enumeration 2751 | +--:(v6ur:next-hop-list) 2752 | +--rw v6ur:next-hop-list 2753 | +--rw v6ur:next-hop* [index] 2754 | +--rw v6ur:index string 2755 | +--rw v6ur:outgoing-interface? 2756 | if:interface-ref 2757 | +--rw v6ur:next-hop-address? 2758 | inet:ipv6-address 2759 +--rw ribs 2760 +--rw rib* [name] 2761 +--rw name string 2762 +--rw address-family? identityref 2763 +--ro default-rib? boolean {multiple-ribs}? 2764 +--ro routes 2765 | +--ro route* 2766 | +--ro route-preference? route-preference 2767 | +--ro next-hop 2768 | | +--ro (next-hop-options) 2769 | | +--:(simple-next-hop) 2770 | | | +--ro outgoing-interface? 2771 | | | | if:interface-ref 2772 | | | +--ro v4ur:next-hop-address? 2773 | | | | inet:ipv4-address 2774 | | | +--ro v6ur:next-hop-address? 2775 | | | inet:ipv6-address 2776 | | +--:(special-next-hop) 2777 | | | +--ro special-next-hop? enumeration 2778 | | +--:(next-hop-list) 2779 | | +--ro next-hop-list 2780 | | +--ro next-hop* 2781 | | +--ro outgoing-interface? 2782 | | | if:interface-ref 2783 | | +--ro v4ur:address? 2784 | | | inet:ipv4-address 2785 | | +--ro v6ur:address? 2786 | | inet:ipv6-address 2787 | +--ro source-protocol identityref 2788 | +--ro active? empty 2789 | +--ro last-updated? yang:date-and-time 2790 | +--ro v4ur:destination-prefix? inet:ipv4-prefix 2791 | +--ro v6ur:destination-prefix? inet:ipv6-prefix 2792 +---x active-route 2793 | +---w input 2794 | | +---w v4ur:destination-address? inet:ipv4-address 2795 | | +---w v6ur:destination-address? inet:ipv6-address 2796 | +--ro output 2797 | +--ro route 2798 | +--ro next-hop 2799 | | +--ro (next-hop-options) 2800 | | +--:(simple-next-hop) 2801 | | | +--ro outgoing-interface? 2802 | | | | if:interface-ref 2803 | | | +--ro v4ur:next-hop-address? 2804 | | | | inet:ipv4-address 2805 | | | +--ro v6ur:next-hop-address? 2806 | | | inet:ipv6-address 2807 | | +--:(special-next-hop) 2808 | | | +--ro special-next-hop? enumeration 2809 | | +--:(next-hop-list) 2810 | | +--ro next-hop-list 2811 | | +--ro next-hop* 2812 | | +--ro outgoing-interface? 2813 | | | if:interface-ref 2814 | | +--ro v4ur:next-hop-address? 2815 | | | inet:ipv4-address 2816 | | +--ro v6ur:next-hop-address? 2817 | | inet:ipv6-address 2818 | +--ro source-protocol identityref 2819 | +--ro active? empty 2820 | +--ro last-updated? yang:date-and-time 2821 | +--ro v4ur:destination-prefix? inet:ipv4-prefix 2822 | +--ro v6ur:destination-prefix? inet:ipv6-prefix 2823 +--rw description? string 2824 module: ietf-ipv6-unicast-routing 2825 augment /if:interfaces/if:interface/ip:ipv6: 2826 +--rw ipv6-router-advertisements 2827 +--rw send-advertisements? boolean 2828 +--rw max-rtr-adv-interval? uint16 2829 +--rw min-rtr-adv-interval? uint16 2830 +--rw managed-flag? boolean 2831 +--rw other-config-flag? boolean 2832 +--rw link-mtu? uint32 2833 +--rw reachable-time? uint32 2834 +--rw retrans-timer? uint32 2835 +--rw cur-hop-limit? uint8 2836 +--rw default-lifetime? uint16 2837 +--rw prefix-list 2838 +--rw prefix* [prefix-spec] 2839 +--rw prefix-spec inet:ipv6-prefix 2840 +--rw (control-adv-prefixes)? 2841 +--:(no-advertise) 2842 | +--rw no-advertise? empty 2843 +--:(advertise) 2844 +--rw valid-lifetime? uint32 2845 +--rw on-link-flag? boolean 2846 +--rw preferred-lifetime? uint32 2847 +--rw autonomous-flag? boolean 2849 Appendix B. Minimum Implementation 2851 Some parts and options of the core routing model, such as user- 2852 defined RIBs, are intended only for advanced routers. This appendix 2853 gives basic non-normative guidelines for implementing a bare minimum 2854 of available functions. Such an implementation may be used for hosts 2855 or very simple routers. 2857 A minimum implementation does not support the feature 2858 "multiple-ribs". This means that a single system-controlled RIB is 2859 available for each supported address family -- IPv4, IPv6, or both. 2860 These RIBs are also the default RIBs. No user-controlled RIBs are 2861 allowed. 2863 In addition to the mandatory instance of the "direct" pseudo- 2864 protocol, a minimum implementation should support configuring 2865 instance(s) of the "static" pseudo-protocol. 2867 For hosts that are never intended to act as routers, the ability to 2868 turn on sending IPv6 router advertisements (Section 5.4) should be 2869 removed. 2871 Platforms with severely constrained resources may use deviations for 2872 restricting the data model, e.g., limiting the number of "static" 2873 control-plane protocol instances. 2875 Appendix C. Example: Adding a New Control-Plane Protocol 2877 This appendix demonstrates how the core routing data model can be 2878 extended to support a new control-plane protocol. The YANG module 2879 "example-rip" shown below is intended as an illustration rather than 2880 a real definition of a data model for the Routing Information 2881 Protocol (RIP). For the sake of brevity, this module does not obey 2882 all the guidelines specified in [RFC6087]. See also Section 5.3.2. 2884 module example-rip { 2886 yang-version "1.1"; 2888 namespace "http://example.com/rip"; 2890 prefix "rip"; 2891 import ietf-interfaces { 2892 prefix "if"; 2893 } 2895 import ietf-routing { 2896 prefix "rt"; 2897 } 2899 identity rip { 2900 base rt:routing-protocol; 2901 description 2902 "Identity for the Routing Information Protocol (RIP)."; 2903 } 2905 typedef rip-metric { 2906 type uint8 { 2907 range "0..16"; 2908 } 2909 } 2911 grouping route-content { 2912 description 2913 "This grouping defines RIP-specific route attributes."; 2914 leaf metric { 2915 type rip-metric; 2916 } 2917 leaf tag { 2918 type uint16; 2919 default "0"; 2920 description 2921 "This leaf may be used to carry additional info, e.g., 2922 autonomous system (AS) number."; 2923 } 2924 } 2926 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { 2927 when "derived-from-or-self(rt:source-protocol, 'rip:rip')" { 2928 description 2929 "This augment is only valid for a route whose source 2930 protocol is RIP."; 2931 } 2932 description 2933 "RIP-specific route attributes."; 2934 uses route-content; 2935 } 2937 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 2938 + "rt:output/rt:route" { 2940 description 2941 "RIP-specific route attributes in the output of 'active-route' 2942 RPC."; 2943 uses route-content; 2944 } 2946 augment "/rt:routing/rt:control-plane-protocols/" 2947 + "rt:control-plane-protocol" { 2948 when "derived-from-or-self(rt:type,'rip:rip')" { 2949 description 2950 "This augment is only valid for a routing protocol instance 2951 of type 'rip'."; 2952 } 2953 container rip { 2954 presence "RIP configuration"; 2955 description 2956 "RIP instance configuration."; 2957 container interfaces { 2958 description 2959 "Per-interface RIP configuration."; 2960 list interface { 2961 key "name"; 2962 description 2963 "RIP is enabled on interfaces that have an entry in this 2964 list, unless 'enabled' is set to 'false' for that 2965 entry."; 2966 leaf name { 2967 type if:interface-ref; 2968 } 2969 leaf enabled { 2970 type boolean; 2971 default "true"; 2972 } 2973 leaf metric { 2974 type rip-metric; 2975 default "1"; 2976 } 2977 } 2978 } 2979 leaf update-interval { 2980 type uint8 { 2981 range "10..60"; 2982 } 2983 units "seconds"; 2984 default "30"; 2985 description 2986 "Time interval between periodic updates."; 2987 } 2989 } 2990 } 2991 } 2993 Appendix D. Data Tree Example 2995 This section contains an example of an instance data tree in the JSON 2996 encoding [RFC7951], containing both configuration and state data. 2997 The data conforms to a data model that is defined by the following 2998 YANG library specification [RFC7895]: 3000 { 3001 "ietf-yang-library:modules-state": { 3002 "module-set-id": "c2e1f54169aa7f36e1a6e8d0865d441d3600f9c4", 3003 "module": [ 3004 { 3005 "name": "ietf-routing", 3006 "revision": "2017-09-13", 3007 "feature": [ 3008 "multiple-ribs", 3009 "router-id" 3010 ], 3011 "namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", 3012 "conformance-type": "implement" 3013 }, 3014 { 3015 "name": "ietf-ipv4-unicast-routing", 3016 "revision": "2017-09-13", 3017 "namespace": 3018 "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing", 3019 "conformance-type": "implement" 3020 }, 3021 { 3022 "name": "ietf-ipv6-unicast-routing", 3023 "revision": "2017-09-13", 3024 "namespace": 3025 "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing-3", 3026 "conformance-type": "implement" 3027 }, 3028 { 3029 "name": "ietf-interfaces", 3030 "revision": "2014-05-08", 3031 "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", 3032 "conformance-type": "implement" 3033 }, 3034 { 3035 "name": "ietf-inet-types", 3036 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 3037 "revision": "2013-07-15", 3038 "conformance-type": "import" 3039 }, 3040 { 3041 "name": "ietf-yang-types", 3042 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 3043 "revision": "2013-07-15", 3044 "conformance-type": "import" 3045 }, 3046 { 3047 "name": "iana-if-type", 3048 "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type", 3049 "revision": "", 3050 "conformance-type": "implement" 3051 }, 3052 { 3053 "name": "ietf-ip", 3054 "revision": "2014-06-16", 3055 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", 3056 "conformance-type": "implement" 3057 } 3058 ] 3059 } 3060 } 3062 A simple network setup as shown in Figure 2 is assumed: router "A" 3063 uses static default routes with the "ISP" router as the next hop. 3064 IPv6 router advertisements are configured only on the "eth1" 3065 interface and disabled on the upstream "eth0" interface. 3067 +-----------------+ 3068 | | 3069 | Router ISP | 3070 | | 3071 +--------+--------+ 3072 |2001:db8:0:1::2 3073 |192.0.2.2 3074 | 3075 | 3076 |2001:db8:0:1::1 3077 eth0|192.0.2.1 3078 +--------+--------+ 3079 | | 3080 | Router A | 3081 | | 3082 +--------+--------+ 3083 eth1|198.51.100.1 3084 |2001:db8:0:2::1 3085 | 3087 Figure 2: Example of Network Configuration 3089 The instance data tree could then be as follows: 3091 { 3092 "ietf-interfaces:interfaces": { 3093 "interface": [ 3094 { 3095 "name": "eth0", 3096 "type": "iana-if-type:ethernetCsmacd", 3097 "description": "Uplink to ISP.", 3098 "ietf-ip:ipv4": { 3099 "address": [ 3100 { 3101 "ip": "192.0.2.1", 3102 "prefix-length": 24 3103 } 3104 ], 3105 "forwarding": true 3106 }, 3107 "ietf-ip:ipv6": { 3108 "address": [ 3109 { 3110 "ip": "2001:0db8:0:1::1", 3111 "prefix-length": 64 3112 } 3113 ], 3114 "forwarding": true, 3115 "autoconf": { 3116 "create-global-addresses": false 3117 } 3118 } 3119 }, 3120 { 3121 "name": "eth1", 3122 "type": "iana-if-type:ethernetCsmacd", 3123 "description": "Interface to the internal network.", 3124 "ietf-ip:ipv4": { 3125 "address": [ 3126 { 3127 "ip": "198.51.100.1", 3128 "prefix-length": 24 3129 } 3130 ], 3131 "forwarding": true 3132 }, 3133 "ietf-ip:ipv6": { 3134 "address": [ 3135 { 3136 "ip": "2001:0db8:0:2::1", 3137 "prefix-length": 64 3138 } 3139 ], 3140 "forwarding": true, 3141 "autoconf": { 3142 "create-global-addresses": false 3143 }, 3144 "ietf-ipv6-unicast-routing: 3145 ipv6-router-advertisements": { 3146 "send-advertisements": true 3147 } 3148 } 3149 } 3150 ] 3151 }, 3152 "ietf-interfaces:interfaces-state": { 3153 "interface": [ 3154 { 3155 "name": "eth0", 3156 "type": "iana-if-type:ethernetCsmacd", 3157 "phys-address": "00:0C:42:E5:B1:E9", 3158 "oper-status": "up", 3159 "statistics": { 3160 "discontinuity-time": "2015-10-24T17:11:27+02:00" 3161 }, 3162 "ietf-ip:ipv4": { 3163 "forwarding": true, 3164 "mtu": 1500, 3165 "address": [ 3166 { 3167 "ip": "192.0.2.1", 3168 "prefix-length": 24 3169 } 3170 ] 3171 }, 3172 "ietf-ip:ipv6": { 3173 "forwarding": true, 3174 "mtu": 1500, 3175 "address": [ 3176 { 3177 "ip": "2001:0db8:0:1::1", 3178 "prefix-length": 64 3179 } 3180 ], 3181 "ietf-ipv6-unicast-routing: 3182 ipv6-router-advertisements": { 3183 "send-advertisements": false 3184 } 3185 } 3186 }, 3187 { 3188 "name": "eth1", 3189 "type": "iana-if-type:ethernetCsmacd", 3190 "phys-address": "00:0C:42:E5:B1:EA", 3191 "oper-status": "up", 3192 "statistics": { 3193 "discontinuity-time": "2015-10-24T17:11:29+02:00" 3194 }, 3195 "ietf-ip:ipv4": { 3196 "forwarding": true, 3197 "mtu": 1500, 3198 "address": [ 3199 { 3200 "ip": "198.51.100.1", 3201 "prefix-length": 24 3202 } 3203 ] 3204 }, 3205 "ietf-ip:ipv6": { 3206 "forwarding": true, 3207 "mtu": 1500, 3208 "address": [ 3209 { 3210 "ip": "2001:0db8:0:2::1", 3211 "prefix-length": 64 3212 } 3213 ], 3214 "ietf-ipv6-unicast-routing: 3215 ipv6-router-advertisements": { 3216 "send-advertisements": true, 3217 "prefix-list": { 3218 "prefix": [ 3219 { 3220 "prefix-spec": "2001:db8:0:2::/64" 3221 } 3222 ] 3223 } 3224 } 3225 } 3226 } 3227 ] 3228 }, 3229 "ietf-routing:routing": { 3230 "router-id": "192.0.2.1", 3231 "control-plane-protocols": { 3232 "control-plane-protocol": [ 3233 { 3234 "type": "ietf-routing:static", 3235 "name": "st0", 3236 "description": 3237 "Static routing is used for the internal network.", 3238 "static-routes": { 3239 "ietf-ipv4-unicast-routing:ipv4": { 3240 "route": [ 3241 { 3242 "destination-prefix": "0.0.0.0/0", 3243 "next-hop": { 3244 "next-hop-address": "192.0.2.2" 3245 } 3246 } 3247 ] 3248 }, 3249 "ietf-ipv6-unicast-routing:ipv6": { 3250 "route": [ 3251 { 3252 "destination-prefix": "::/0", 3253 "next-hop": { 3254 "next-hop-address": "2001:db8:0:1::2" 3255 } 3256 } 3257 ] 3258 } 3260 } 3261 } 3262 ] 3263 } 3264 "ribs": { 3265 "rib": [ 3266 { 3267 "name": "ipv4-master", 3268 "address-family": 3269 "ietf-ipv4-unicast-routing:ipv4-unicast", 3270 "default-rib": true, 3271 "routes": { 3272 "route": [ 3273 { 3274 "ietf-ipv4-unicast-routing:destination-prefix": 3275 "192.0.2.1/24", 3276 "next-hop": { 3277 "outgoing-interface": "eth0" 3278 }, 3279 "route-preference": 0, 3280 "source-protocol": "ietf-routing:direct", 3281 "last-updated": "2015-10-24T17:11:27+02:00" 3282 }, 3283 { 3284 "ietf-ipv4-unicast-routing:destination-prefix": 3285 "198.51.100.0/24", 3286 "next-hop": { 3287 "outgoing-interface": "eth1" 3288 }, 3289 "source-protocol": "ietf-routing:direct", 3290 "route-preference": 0, 3291 "last-updated": "2015-10-24T17:11:27+02:00" 3292 }, 3293 { 3294 "ietf-ipv4-unicast-routing:destination-prefix": 3295 "0.0.0.0/0", 3296 "source-protocol": "ietf-routing:static", 3297 "route-preference": 5, 3298 "next-hop": { 3299 "ietf-ipv4-unicast-routing:next-hop-address": 3300 "192.0.2.2" 3301 }, 3302 "last-updated": "2015-10-24T18:02:45+02:00" 3303 } 3304 ] 3305 } 3306 }, 3307 { 3308 "name": "ipv6-master", 3309 "address-family": 3310 "ietf-ipv6-unicast-routing:ipv6-unicast", 3311 "default-rib": true, 3312 "routes": { 3313 "route": [ 3314 { 3315 "ietf-ipv6-unicast-routing:destination-prefix": 3316 "2001:db8:0:1::/64", 3317 "next-hop": { 3318 "outgoing-interface": "eth0" 3319 }, 3320 "source-protocol": "ietf-routing:direct", 3321 "route-preference": 0, 3322 "last-updated": "2015-10-24T17:11:27+02:00" 3323 }, 3324 { 3325 "ietf-ipv6-unicast-routing:destination-prefix": 3326 "2001:db8:0:2::/64", 3327 "next-hop": { 3328 "outgoing-interface": "eth1" 3329 }, 3330 "source-protocol": "ietf-routing:direct", 3331 "route-preference": 0, 3332 "last-updated": "2015-10-24T17:11:27+02:00" 3333 }, 3334 { 3335 "ietf-ipv6-unicast-routing:destination-prefix": 3336 "::/0", 3337 "next-hop": { 3338 "ietf-ipv6-unicast-routing:next-hop-address": 3339 "2001:db8:0:1::2" 3340 }, 3341 "source-protocol": "ietf-routing:static", 3342 "route-preference": 5, 3343 "last-updated": "2015-10-24T18:02:45+02:00" 3344 } 3345 ] 3346 } 3347 } 3348 ] 3349 } 3350 }, 3351 } 3353 Acknowledgments 3355 The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean 3356 Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini, 3357 David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane 3358 Litkowski, Thomas Morin, Tom Petch, Yingzhen Qu, Bruno Rijsman, 3359 Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, 3360 Derek Man-Kit Yeung, Jeffrey Zhang, Vladimir Vassilev, and Rob Wilton 3361 for their helpful comments and suggestions. 3363 Authors' Addresses 3365 Ladislav Lhotka 3366 CZ.NIC 3368 EMail: lhotka@nic.cz 3370 Acee Lindem 3371 Cisco Systems 3373 EMail: acee@cisco.com 3375 Yingzhen Qu 3376 Futurewei Technologies, Inc. 3377 2330 Central Expressway 3378 Santa Clara CA 95050 3379 USA 3381 EMail: yingzhen.qu@huawei.com