doc: Add RFC documents

1 files changed, 3587 insertions, 0 deletions

diff --git a/doc/rfc/rfc8022.txt b/doc/rfc/rfc8022.txt
new file mode 100644
index 0000000..44f975d
--- /dev/null
+++ b/doc/rfc/rfc8022.txt
@@ -0,0 +1,3587 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         L. Lhotka
+Request for Comments: 8022                                        CZ.NIC
+Category: Standards Track                                      A. Lindem
+ISSN: 2070-1721                                            Cisco Systems
+                                                           November 2016
+
+
+                A YANG Data Model for Routing Management
+
+Abstract
+
+   This document contains a specification of three YANG modules and one
+   submodule.  Together they form the core routing data model that
+   serves as a framework for configuring and managing a routing
+   subsystem.  It is expected that these modules will be augmented by
+   additional YANG modules defining data models for control-plane
+   protocols, route filters, and other functions.  The core routing data
+   model provides common building blocks for such extensions -- routes,
+   Routing Information Bases (RIBs), and control-plane protocols.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8022.
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Lhotka & Lindem              Standards Track                    [Page 1]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology and Notation  . . . . . . . . . . . . . . . . . .   3
+     2.1.  Glossary of New Terms . . . . . . . . . . . . . . . . . .   4
+     2.2.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   5
+     2.3.  Prefixes in Data Node Names . . . . . . . . . . . . . . .   5
+   3.  Objectives  . . . . . . . . . . . . . . . . . . . . . . . . .   6
+   4.  The Design of the Core Routing Data Model . . . . . . . . . .   6
+     4.1.  System-Controlled and User-Controlled List Entries  . . .   8
+   5.  Basic Building Blocks . . . . . . . . . . . . . . . . . . . .   9
+     5.1.  Route . . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     5.2.  Routing Information Base (RIB)  . . . . . . . . . . . . .   9
+     5.3.  Control-Plane Protocol  . . . . . . . . . . . . . . . . .  10
+       5.3.1.  Routing Pseudo-Protocols  . . . . . . . . . . . . . .  10
+       5.3.2.  Defining New Control-Plane Protocols  . . . . . . . .  11
+     5.4.  Parameters of IPv6 Router Advertisements  . . . . . . . .  12
+   6.  Interactions with Other YANG Modules  . . . . . . . . . . . .  13
+     6.1.  Module "ietf-interfaces"  . . . . . . . . . . . . . . . .  13
+     6.2.  Module "ietf-ip"  . . . . . . . . . . . . . . . . . . . .  13
+   7.  Routing Management YANG Module  . . . . . . . . . . . . . . .  14
+   8.  IPv4 Unicast Routing Management YANG Module . . . . . . . . .  26
+   9.  IPv6 Unicast Routing Management YANG Module . . . . . . . . .  32
+     9.1.  IPv6 Router Advertisements Submodule  . . . . . . . . . .  37
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
+   11. Security Considerations . . . . . . . . . . . . . . . . . . .  48
+   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  49
+     12.1.  Normative References . . . . . . . . . . . . . . . . . .  49
+     12.2.  Informative References . . . . . . . . . . . . . . . . .  50
+   Appendix A.  The Complete Data Trees  . . . . . . . . . . . . . .  51
+     A.1.  Configuration Data  . . . . . . . . . . . . . . . . . . .  51
+     A.2.  State Data  . . . . . . . . . . . . . . . . . . . . . . .  52
+   Appendix B.  Minimum Implementation . . . . . . . . . . . . . . .  53
+   Appendix C.  Example: Adding a New Control-Plane Protocol . . . .  54
+   Appendix D.  Data Tree Example  . . . . . . . . . . . . . . . . .  56
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  64
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  64
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                    [Page 2]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+1.  Introduction
+
+   This document contains a specification of the following YANG modules:
+
+   o  The "ietf-routing" module provides generic components of a routing
+      data model.
+
+   o  The "ietf-ipv4-unicast-routing" module augments the "ietf-routing"
+      module with additional data specific to IPv4 unicast.
+
+   o  The "ietf-ipv6-unicast-routing" module augments the "ietf-routing"
+      module with additional data specific to IPv6 unicast.  Its
+      submodule "ietf-ipv6-router-advertisements" also augments the
+      "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277] modules with
+      IPv6 router configuration variables required by [RFC4861].
+
+   These modules together define the so-called core routing data model,
+   which is intended as a basis for future data model development
+   covering more-sophisticated routing systems.  While these three
+   modules can be directly used for simple IP devices with static
+   routing (see Appendix B), their main purpose is to provide essential
+   building blocks for more-complicated data models involving multiple
+   control-plane protocols, multicast routing, additional address
+   families, and advanced functions such as route filtering or policy
+   routing.  To this end, it is expected that the core routing data
+   model will be augmented by numerous modules developed by various IETF
+   working groups.
+
+2.  Terminology and Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The following terms are defined in [RFC6241]:
+
+   o  client
+
+   o  message
+
+   o  protocol operation
+
+   o  server
+
+   The following terms are defined in [RFC7950]:
+
+   o  action
+
+
+
+
+Lhotka & Lindem              Standards Track                    [Page 3]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+   o  augment
+
+   o  configuration data
+
+   o  container
+
+   o  container with presence
+
+   o  data model
+
+   o  data node
+
+   o  feature
+
+   o  leaf
+
+   o  list
+
+   o  mandatory node
+
+   o  module
+
+   o  schema tree
+
+   o  state data
+
+   o  RPC (Remote Procedure Call) operation
+
+2.1.  Glossary of New Terms
+
+   core routing data model:  YANG data model comprising "ietf-routing",
+      "ietf-ipv4-unicast-routing", and "ietf-ipv6-unicast-routing"
+      modules.
+
+   direct route:  a route to a directly connected network.
+
+   Routing Information Base (RIB):  An object containing a list of
+      routes together with other information.  See Section 5.2 for
+      details.
+
+   system-controlled entry:  An entry of a list in state data ("config
+      false") that is created by the system independently of what has
+      been explicitly configured.  See Section 4.1 for details.
+
+   user-controlled entry:  An entry of a list in state data ("config
+      false") that is created and deleted as a direct consequence of
+      certain configuration changes.  See Section 4.1 for details.
+
+
+
+
+Lhotka & Lindem              Standards Track                    [Page 4]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+2.2.  Tree Diagrams
+
+   A simplified graphical representation of the complete data tree is
+   presented in Appendix A, and similar diagrams of its various subtrees
+   appear in the main text.
+
+   o  Brackets "[" and "]" enclose list keys.
+
+   o  Curly braces "{" and "}" contain names of optional features that
+      make the corresponding node conditional.
+
+   o  Abbreviations before data node names: "rw" means configuration
+      (read-write), "ro" state data (read-only), "-x" RPC operations or
+      actions, and "-n" notifications.
+
+   o  Symbols after data node names: "?" means an optional node, "!" a
+      container with presence, and "*" denotes a "list" or "leaf-list".
+
+   o  Parentheses enclose choice and case nodes, and case nodes are also
+      marked with a colon (":").
+
+   o  Ellipsis ("...") stands for contents of subtrees that are not
+      shown.
+
+2.3.  Prefixes in Data Node Names
+
+   In this document, names of data nodes, actions, and other data model
+   objects are often used without a prefix, as long as it is clear from
+   the context in which YANG module each name is defined.  Otherwise,
+   names are prefixed using the standard prefix associated with the
+   corresponding YANG module, as shown in Table 1.
+
+            +--------+---------------------------+-----------+
+            | Prefix | YANG module               | Reference |
+            +--------+---------------------------+-----------+
+            | if     | ietf-interfaces           | [RFC7223] |
+            | ip     | ietf-ip                   | [RFC7277] |
+            | rt     | ietf-routing              | Section 7 |
+            | v4ur   | ietf-ipv4-unicast-routing | Section 8 |
+            | v6ur   | ietf-ipv6-unicast-routing | Section 9 |
+            | yang   | ietf-yang-types           | [RFC6991] |
+            | inet   | ietf-inet-types           | [RFC6991] |
+            +--------+---------------------------+-----------+
+
+             Table 1: Prefixes and Corresponding YANG Modules
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                    [Page 5]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+3.  Objectives
+
+   The initial design of the core routing data model was driven by the
+   following objectives:
+
+   o  The data model should be suitable for the common address families
+      -- in particular, IPv4 and IPv6 -- and for unicast and multicast
+      routing, as well as Multiprotocol Label Switching (MPLS).
+
+   o  A simple IP routing system, such as one that uses only static
+      routing, should be configurable in a simple way, ideally without
+      any need to develop additional YANG modules.
+
+   o  On the other hand, the core routing framework must allow for
+      complicated implementations involving multiple Routing Information
+      Bases (RIBs) and multiple control-plane protocols, as well as
+      controlled redistributions of routing information.
+
+   o  Because device vendors will want to map the data models built on
+      this generic framework to their proprietary data models and
+      configuration interfaces, the framework should be flexible enough
+      to facilitate that and accommodate data models with different
+      logic.
+
+4.  The Design of the Core Routing Data Model
+
+   The core routing data model consists of three YANG modules and one
+   submodule.  The first module, "ietf-routing", defines the generic
+   components of a routing system.  The other two modules, "ietf-ipv4-
+   unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf-
+   routing" module with additional data nodes that are needed for IPv4
+   and IPv6 unicast routing, respectively.  The "ietf-ipv6-unicast-
+   routing" module has a submodule, "ietf-ipv6-router-advertisements",
+   that augments the "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277]
+   modules with configuration variables for IPv6 router advertisements
+   as required by [RFC4861].  Figures 1 and 2 show abridged views of the
+   configuration and state data hierarchies.  See Appendix A for the
+   complete data trees.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                    [Page 6]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+   +--rw routing
+      +--rw router-id?
+      +--rw control-plane-protocols
+      |  +--rw control-plane-protocol* [type name]
+      |     +--rw type
+      |     +--rw name
+      |     +--rw description?
+      |     +--rw static-routes
+      |        +--rw v6ur:ipv6
+      |        |     ...
+      |        +--rw v4ur:ipv4
+      |              ...
+      +--rw ribs
+         +--rw rib* [name]
+            +--rw name
+            +--rw address-family?
+            +--rw description?
+
+                  Figure 1: Configuration Data Hierarchy
+
+   +--ro routing-state
+      +--ro router-id?
+      +--ro interfaces
+      |  +--ro interface*
+      +--ro control-plane-protocols
+      |  +--ro control-plane-protocol* [type name]
+      |     +--ro type
+      |     +--ro name
+      +--ro ribs
+         +--ro rib* [name]
+            +--ro name
+            +--ro address-family
+            +--ro default-rib?
+            +--ro routes
+            |  +--ro route*
+            |        ...
+
+                      Figure 2: State Data Hierarchy
+
+   As can be seen from Figures 1 and 2, the core routing data model
+   introduces several generic components of a routing framework: routes,
+   RIBs containing lists of routes, and control-plane protocols.
+   Section 5 describes these components in more detail.
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                    [Page 7]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+4.1.  System-Controlled and User-Controlled List Entries
+
+   The core routing data model defines several lists in the schema tree,
+   such as "rib", that have to be populated with at least one entry in
+   any properly functioning device, and additional entries may be
+   configured by a client.
+
+   In such a list, the server creates the required item as a so-called
+   system-controlled entry in state data, i.e., inside the "routing-
+   state" container.
+
+   An example can be seen in Appendix D: the "/routing-state/ribs/rib"
+   list has two system-controlled entries named "ipv4-master" and
+   "ipv6-master".
+
+   Additional entries may be created in the configuration by a client,
+   e.g., via the NETCONF protocol.  These are so-called user-controlled
+   entries.  If the server accepts a configured user-controlled entry,
+   then this entry also appears in the state data version of the list.
+
+   Corresponding entries in both versions of the list (in state data and
+   configuration) have the same value of the list key.
+
+   A client may also provide supplemental configuration of system-
+   controlled entries.  To do so, the client creates a new entry in the
+   configuration with the desired contents.  In order to bind this entry
+   to the corresponding entry in the state data list, the key of the
+   configuration entry has to be set to the same value as the key of the
+   state entry.
+
+   Deleting a user-controlled entry from the configuration list results
+   in the removal of the corresponding entry in the state data list.  In
+   contrast, if a system-controlled entry is deleted from the
+   configuration list, only the extra configuration specified in that
+   entry is removed but the corresponding state data entry remains in
+   the list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                    [Page 8]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+5.  Basic Building Blocks
+
+   This section describes the essential components of the core routing
+   data model.
+
+5.1.  Route
+
+   Routes are basic elements of information in a routing system.  The
+   core routing data model defines only the following minimal set of
+   route attributes:
+
+   o  "destination-prefix": address prefix specifying the set of
+      destination addresses for which the route may be used.  This
+      attribute is mandatory.
+
+   o  "route-preference": an integer value (also known as administrative
+      distance) that is used for selecting a preferred route among
+      routes with the same destination prefix.  A lower value means a
+      more preferred route.
+
+   o  "next-hop": determines the outgoing interface and/or next-hop
+      address(es), or a special operation to be performed with a packet.
+
+   Routes are primarily state data that appear as entries of RIBs
+   (Section 5.2) but they may also be found in configuration data, for
+   example, as manually configured static routes.  In the latter case,
+   configurable route attributes are generally a subset of attributes
+   defined for RIB routes.
+
+5.2.  Routing Information Base (RIB)
+
+   Every implementation of the core routing data model manages one or
+   more Routing Information Bases (RIBs).  A RIB is a list of routes
+   complemented with administrative data.  Each RIB contains only routes
+   of one address family.  An address family is represented by an
+   identity derived from the "rt:address-family" base identity.
+
+   In the core routing data model, RIBs are state data represented as
+   entries of the list "/routing-state/ribs/rib".  The contents of RIBs
+   are controlled and manipulated by control-plane protocol operations
+   that may result in route additions, removals, and modifications.
+   This also includes manipulations via the "static" and/or "direct"
+   pseudo-protocols; see Section 5.3.1.
+
+   For every supported address family, exactly one RIB MUST be marked as
+   the so-called default RIB to which control-plane protocols place
+   their routes by default.
+
+
+
+
+Lhotka & Lindem              Standards Track                    [Page 9]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+   Simple router implementations that do not advertise the feature
+   "multiple-ribs" will typically create one system-controlled RIB per
+   supported address family and mark it as the default RIB.
+
+   More-complex router implementations advertising the "multiple-ribs"
+   feature support multiple RIBs per address family that can be used for
+   policy routing and other purposes.
+
+   The following action (see Section 7.15 of [RFC7950]) is defined for
+   the "rib" list:
+
+   o  active-route -- return the active RIB route for the destination
+      address that is specified as the action's input parameter.
+
+5.3.  Control-Plane Protocol
+
+   The core routing data model provides an open-ended framework for
+   defining multiple control-plane protocol instances, e.g., for Layer 3
+   routing protocols.  Each control-plane protocol instance MUST be
+   assigned a type, which is an identity derived from the
+   "rt:control-plane-protocol" base identity.  The core routing data
+   model defines two identities for the direct and static pseudo-
+   protocols (Section 5.3.1).
+
+   Multiple control-plane protocol instances of the same type MAY be
+   configured.
+
+5.3.1.  Routing Pseudo-Protocols
+
+   The core routing data model defines two special routing protocol
+   types -- "direct" and "static".  Both are in fact pseudo-protocols,
+   which means that they are confined to the local device and do not
+   exchange any routing information with adjacent routers.
+
+   Every implementation of the core routing data model MUST provide
+   exactly one instance of the "direct" pseudo-protocol type.  It is the
+   source of direct routes for all configured address families.  Direct
+   routes are normally supplied by the operating system kernel, based on
+   the configuration of network interface addresses; see Section 6.2.
+
+   A pseudo-protocol of the type "static" allows for specifying routes
+   manually.  It MAY be configured in zero or multiple instances,
+   although a typical configuration will have exactly one instance.
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 10]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+5.3.2.  Defining New Control-Plane Protocols
+
+   It is expected that future YANG modules will create data models for
+   additional control-plane protocol types.  Such a new module has to
+   define the protocol-specific configuration and state data, and it has
+   to integrate it into the core routing framework in the following way:
+
+   o  A new identity MUST be defined for the control-plane protocol, and
+      its base identity MUST be set to "rt:control-plane-protocol" or to
+      an identity derived from "rt:control-plane-protocol".
+
+   o  Additional route attributes MAY be defined, preferably in one
+      place by means of defining a YANG grouping.  The new attributes
+      have to be inserted by augmenting the definitions of the nodes
+
+       /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
+
+      and
+
+       /rt:routing-state/rt:ribs/rt:rib/rt:output/rt:route,
+
+      and possibly other places in the configuration, state data,
+      notifications, and input/output parameters of actions or RPC
+      operations.
+
+   o  Configuration parameters and/or state data for the new protocol
+      can be defined by augmenting the "control-plane-protocol" data
+      node under both "/routing" and "/routing-state".
+
+   By using a "when" statement, the augmented configuration parameters
+   and state data specific to the new protocol SHOULD be made
+   conditional and valid only if the value of "rt:type" or
+   "rt:source-protocol" is equal to (or derived from) the new protocol's
+   identity.
+
+   It is also RECOMMENDED that protocol-specific data nodes be
+   encapsulated in an appropriately named container with presence.  Such
+   a container may contain mandatory data nodes that are otherwise
+   forbidden at the top level of an augment.
+
+   The above steps are implemented by the example YANG module for the
+   Routing Information Protocol (RIP) in Appendix C.
+
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 11]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+5.4.  Parameters of IPv6 Router Advertisements
+
+   YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is
+   a submodule of the "ietf-ipv6-unicast-routing" module, augments the
+   configuration and state data of IPv6 interfaces with definitions of
+   the following variables as required by Section 6.2.1 of [RFC4861]:
+
+   o  send-advertisements
+
+   o  max-rtr-adv-interval
+
+   o  min-rtr-adv-interval
+
+   o  managed-flag
+
+   o  other-config-flag
+
+   o  link-mtu
+
+   o  reachable-time
+
+   o  retrans-timer
+
+   o  cur-hop-limit
+
+   o  default-lifetime
+
+   o  prefix-list: a list of prefixes to be advertised.
+
+      The following parameters are associated with each prefix in the
+      list:
+
+      *  valid-lifetime
+
+      *  on-link-flag
+
+      *  preferred-lifetime
+
+      *  autonomous-flag
+
+   NOTES:
+
+   1.  The "IsRouter" flag, which is also required by [RFC4861], is
+       implemented in the "ietf-ip" module [RFC7277] (leaf
+       "ip:forwarding").
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 12]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+   2.  The original specification [RFC4861] allows the implementations
+       to decide whether the "valid-lifetime" and "preferred-lifetime"
+       parameters remain the same in consecutive advertisements or
+       decrement in real time.  However, the latter behavior seems
+       problematic because the values might be reset again to the
+       (higher) configured values after a configuration is reloaded.
+       Moreover, no implementation is known to use the decrementing
+       behavior.  The "ietf-ipv6-router-advertisements" submodule
+       therefore stipulates the former behavior with constant values.
+
+6.  Interactions with Other YANG Modules
+
+   The semantics of the core routing data model also depends on several
+   configuration parameters that are defined in other YANG modules.
+
+6.1.  Module "ietf-interfaces"
+
+   The following boolean switch is defined in the "ietf-interfaces" YANG
+   module [RFC7223]:
+
+   /if:interfaces/if:interface/if:enabled
+
+      If this switch is set to "false" for a network-layer interface,
+      then all routing and forwarding functions MUST be disabled on this
+      interface.
+
+6.2.  Module "ietf-ip"
+
+   The following boolean switches are defined in the "ietf-ip" YANG
+   module [RFC7277]:
+
+   /if:interfaces/if:interface/ip:ipv4/ip:enabled
+
+      If this switch is set to "false" for a network-layer interface,
+      then all IPv4 routing and forwarding functions MUST be disabled on
+      this interface.
+
+   /if:interfaces/if:interface/ip:ipv4/ip:forwarding
+
+      If this switch is set to "false" for a network-layer interface,
+      then the forwarding of IPv4 datagrams through this interface MUST
+      be disabled.  However, the interface MAY participate in other IPv4
+      routing functions, such as routing protocols.
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 13]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+   /if:interfaces/if:interface/ip:ipv6/ip:enabled
+
+      If this switch is set to "false" for a network-layer interface,
+      then all IPv6 routing and forwarding functions MUST be disabled on
+      this interface.
+
+   /if:interfaces/if:interface/ip:ipv6/ip:forwarding
+
+      If this switch is set to "false" for a network-layer interface,
+      then the forwarding of IPv6 datagrams through this interface MUST
+      be disabled.  However, the interface MAY participate in other IPv6
+      routing functions, such as routing protocols.
+
+   In addition, the "ietf-ip" module allows for configuring IPv4 and
+   IPv6 addresses and network prefixes or masks on network-layer
+   interfaces.  Configuration of these parameters on an enabled
+   interface MUST result in an immediate creation of the corresponding
+   direct route.  The destination prefix of this route is set according
+   to the configured IP address and network prefix/mask, and the
+   interface is set as the outgoing interface for that route.
+
+7.  Routing Management YANG Module
+
+   <CODE BEGINS> file "ietf-routing@2016-11-04.yang"
+
+   module ietf-routing {
+
+     yang-version "1.1";
+
+     namespace "urn:ietf:params:xml:ns:yang:ietf-routing";
+
+     prefix "rt";
+
+     import ietf-yang-types {
+       prefix "yang";
+     }
+
+     import ietf-interfaces {
+       prefix "if";
+     }
+
+     organization
+       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
+
+     contact
+       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
+        WG List:  <mailto:netmod@ietf.org>
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 14]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+        WG Chair: Lou Berger
+                  <mailto:lberger@labn.net>
+
+        WG Chair: Kent Watsen
+                  <mailto:kwatsen@juniper.net>
+
+        Editor:   Ladislav Lhotka
+                  <mailto:lhotka@nic.cz>
+
+        Editor:   Acee Lindem
+                  <mailto:acee@cisco.com>";
+
+     description
+       "This YANG module defines essential components for the management
+        of a routing subsystem.
+
+        Copyright (c) 2016 IETF Trust and the persons identified as
+        authors of the code.  All rights reserved.
+
+        Redistribution and use in source and binary forms, with or
+        without modification, is permitted pursuant to, and subject to
+        the license terms contained in, the Simplified BSD License set
+        forth in Section 4.c of the IETF Trust's Legal Provisions
+        Relating to IETF Documents
+        (http://trustee.ietf.org/license-info).
+
+        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
+        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
+        'OPTIONAL' in the module text are to be interpreted as described
+        in RFC 2119.
+
+        This version of this YANG module is part of RFC 8022;
+        see the RFC itself for full legal notices.";
+
+     revision 2016-11-04 {
+       description
+         "Initial revision.";
+       reference
+         "RFC 8022: A YANG Data Model for Routing Management";
+     }
+
+     /* Features */
+
+     feature multiple-ribs {
+       description
+         "This feature indicates that the server supports user-defined
+          RIBs.
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 15]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+          Servers that do not advertise this feature SHOULD provide
+          exactly one system-controlled RIB per supported address family
+          and make it also the default RIB.  This RIB then appears as an
+          entry of the list /routing-state/ribs/rib.";
+     }
+
+     feature router-id {
+       description
+         "This feature indicates that the server supports configuration
+          of an explicit 32-bit router ID that is used by some routing
+          protocols.
+
+          Servers that do not advertise this feature set a router ID
+          algorithmically, usually to one of the configured IPv4
+          addresses.  However, this algorithm is implementation
+          specific.";
+     }
+
+     /* Identities */
+
+     identity address-family {
+       description
+         "Base identity from which identities describing address
+          families are derived.";
+     }
+
+     identity ipv4 {
+       base address-family;
+       description
+         "This identity represents IPv4 address family.";
+     }
+
+     identity ipv6 {
+       base address-family;
+       description
+         "This identity represents IPv6 address family.";
+     }
+
+     identity control-plane-protocol {
+       description
+         "Base identity from which control-plane protocol identities are
+          derived.";
+     }
+
+     identity routing-protocol {
+       base control-plane-protocol;
+       description
+         "Identity from which Layer 3 routing protocol identities are
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 16]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+          derived.";
+     }
+
+     identity direct {
+       base routing-protocol;
+       description
+         "Routing pseudo-protocol that provides routes to directly
+          connected networks.";
+     }
+
+     identity static {
+       base routing-protocol;
+       description
+         "Static routing pseudo-protocol.";
+     }
+
+     /* Type Definitions */
+
+     typedef route-preference {
+       type uint32;
+       description
+         "This type is used for route preferences.";
+     }
+
+     /* Groupings */
+
+     grouping address-family {
+       description
+         "This grouping provides a leaf identifying an address
+          family.";
+       leaf address-family {
+         type identityref {
+           base address-family;
+         }
+         mandatory "true";
+         description
+           "Address family.";
+       }
+     }
+
+     grouping router-id {
+       description
+         "This grouping provides router ID.";
+       leaf router-id {
+         type yang:dotted-quad;
+         description
+           "A 32-bit number in the form of a dotted quad that is used by
+            some routing protocols identifying a router.";
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 17]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+         reference
+           "RFC 2328: OSPF Version 2.";
+       }
+     }
+
+     grouping special-next-hop {
+       description
+         "This grouping provides a leaf with an enumeration of special
+          next hops.";
+       leaf special-next-hop {
+         type enumeration {
+           enum blackhole {
+             description
+               "Silently discard the packet.";
+           }
+           enum unreachable {
+             description
+               "Discard the packet and notify the sender with an error
+                message indicating that the destination host is
+                unreachable.";
+           }
+           enum prohibit {
+             description
+               "Discard the packet and notify the sender with an error
+                message indicating that the communication is
+                administratively prohibited.";
+           }
+           enum receive {
+             description
+               "The packet will be received by the local system.";
+           }
+         }
+         description
+           "Options for special next hops.";
+       }
+     }
+
+     grouping next-hop-content {
+       description
+         "Generic parameters of next hops in static routes.";
+       choice next-hop-options {
+         mandatory "true";
+         description
+           "Options for next hops in static routes.
+
+            It is expected that further cases will be added through
+            augments from other modules.";
+         case simple-next-hop {
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 18]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+           description
+             "This case represents a simple next hop consisting of the
+              next-hop address and/or outgoing interface.
+
+              Modules for address families MUST augment this case with a
+              leaf containing a next-hop address of that address
+              family.";
+           leaf outgoing-interface {
+             type if:interface-ref;
+             description
+               "Name of the outgoing interface.";
+           }
+         }
+         case special-next-hop {
+           uses special-next-hop;
+         }
+         case next-hop-list {
+           container next-hop-list {
+             description
+               "Container for multiple next-hops.";
+             list next-hop {
+               key "index";
+               description
+                 "An entry of a next-hop list.
+
+                  Modules for address families MUST augment this list
+                  with a leaf containing a next-hop address of that
+                  address family.";
+               leaf index {
+                 type string;
+                 description
+                   "A user-specified identifier utilized to uniquely
+                    reference the next-hop entry in the next-hop list.
+                    The value of this index has no semantic meaning
+                    other than for referencing the entry.";
+               }
+               leaf outgoing-interface {
+                 type if:interface-ref;
+                 description
+                   "Name of the outgoing interface.";
+               }
+             }
+           }
+         }
+       }
+     }
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 19]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+     grouping next-hop-state-content {
+       description
+         "Generic parameters of next hops in state data.";
+       choice next-hop-options {
+         mandatory "true";
+         description
+           "Options for next hops in state data.
+
+            It is expected that further cases will be added through
+            augments from other modules, e.g., for recursive
+            next hops.";
+         case simple-next-hop {
+           description
+             "This case represents a simple next hop consisting of the
+              next-hop address and/or outgoing interface.
+
+              Modules for address families MUST augment this case with a
+              leaf containing a next-hop address of that address
+              family.";
+           leaf outgoing-interface {
+             type if:interface-state-ref;
+             description
+               "Name of the outgoing interface.";
+           }
+         }
+         case special-next-hop {
+           uses special-next-hop;
+         }
+         case next-hop-list {
+           container next-hop-list {
+             description
+               "Container for multiple next hops.";
+             list next-hop {
+               description
+                 "An entry of a next-hop list.
+
+                  Modules for address families MUST augment this list
+                  with a leaf containing a next-hop address of that
+                  address family.";
+               leaf outgoing-interface {
+                 type if:interface-state-ref;
+                 description
+                   "Name of the outgoing interface.";
+               }
+             }
+           }
+         }
+       }
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 20]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+     }
+
+     grouping route-metadata {
+       description
+         "Common route metadata.";
+       leaf source-protocol {
+         type identityref {
+           base routing-protocol;
+         }
+         mandatory "true";
+         description
+           "Type of the routing protocol from which the route
+            originated.";
+       }
+       leaf active {
+         type empty;
+         description
+           "Presence of this leaf indicates that the route is preferred
+            among all routes in the same RIB that have the same
+            destination prefix.";
+       }
+       leaf last-updated {
+         type yang:date-and-time;
+         description
+           "Time stamp of the last modification of the route.  If the
+            route was never modified, it is the time when the route was
+            inserted into the RIB.";
+       }
+     }
+
+     /* State data */
+
+     container routing-state {
+       config "false";
+       description
+         "State data of the routing subsystem.";
+       uses router-id {
+         description
+           "Global router ID.
+
+            It may be either configured or assigned algorithmically by
+            the implementation.";
+       }
+       container interfaces {
+         description
+           "Network-layer interfaces used for routing.";
+         leaf-list interface {
+           type if:interface-state-ref;
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 21]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+           description
+             "Each entry is a reference to the name of a configured
+              network-layer interface.";
+         }
+       }
+       container control-plane-protocols {
+         description
+           "Container for the list of routing protocol instances.";
+         list control-plane-protocol {
+           key "type name";
+           description
+             "State data of a control-plane protocol instance.
+
+              An implementation MUST provide exactly one
+              system-controlled instance of the 'direct'
+              pseudo-protocol.  Instances of other control-plane
+              protocols MAY be created by configuration.";
+           leaf type {
+             type identityref {
+               base control-plane-protocol;
+             }
+             description
+               "Type of the control-plane protocol.";
+           }
+           leaf name {
+             type string;
+             description
+               "The name of the control-plane protocol instance.
+
+                For system-controlled instances this name is persistent,
+                i.e., it SHOULD NOT change across reboots.";
+           }
+         }
+       }
+       container ribs {
+         description
+           "Container for RIBs.";
+         list rib {
+           key "name";
+           min-elements "1";
+           description
+             "Each entry represents a RIB identified by the 'name' key.
+              All routes in a RIB MUST belong to the same address
+              family.
+
+              An implementation SHOULD provide one system-controlled
+              default RIB for each supported address family.";
+           leaf name {
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 22]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+             type string;
+             description
+               "The name of the RIB.";
+           }
+           uses address-family;
+           leaf default-rib {
+             if-feature "multiple-ribs";
+             type boolean;
+             default "true";
+             description
+               "This flag has the value of 'true' if and only if the RIB
+                is the default RIB for the given address family.
+
+                By default, control-plane protocols place their routes
+                in the default RIBs.";
+           }
+           container routes {
+             description
+               "Current content of the RIB.";
+             list route {
+               description
+                 "A RIB route entry.  This data node MUST be augmented
+                  with information specific for routes of each address
+                  family.";
+               leaf route-preference {
+                 type route-preference;
+                 description
+                   "This route attribute, also known as administrative
+                    distance, allows for selecting the preferred route
+                    among routes with the same destination prefix.  A
+                    smaller value means a more preferred route.";
+               }
+               container next-hop {
+                 description
+                   "Route's next-hop attribute.";
+                 uses next-hop-state-content;
+               }
+               uses route-metadata;
+             }
+           }
+           action active-route {
+             description
+               "Return the active RIB route that is used for the
+                destination address.
+
+                Address-family-specific modules MUST augment input
+                parameters with a leaf named 'destination-address'.";
+             output {
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 23]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+               container route {
+                 description
+                   "The active RIB route for the specified destination.
+
+                    If no route exists in the RIB for the destination
+                    address, no output is returned.
+
+                    Address-family-specific modules MUST augment this
+                    container with appropriate route contents.";
+                 container next-hop {
+                   description
+                     "Route's next-hop attribute.";
+                   uses next-hop-state-content;
+                 }
+                 uses route-metadata;
+               }
+             }
+           }
+         }
+       }
+     }
+
+     /* Configuration Data */
+
+     container routing {
+       description
+         "Configuration parameters for the routing subsystem.";
+       uses router-id {
+         if-feature "router-id";
+         description
+           "Configuration of the global router ID.  Routing protocols
+            that use router ID can use this parameter or override it
+            with another value.";
+       }
+       container control-plane-protocols {
+         description
+           "Configuration of control-plane protocol instances.";
+         list control-plane-protocol {
+           key "type name";
+           description
+             "Each entry contains configuration of a control-plane
+              protocol instance.";
+           leaf type {
+             type identityref {
+               base control-plane-protocol;
+             }
+             description
+               "Type of the control-plane protocol - an identity derived
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 24]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+                from the 'control-plane-protocol' base identity.";
+           }
+           leaf name {
+             type string;
+             description
+               "An arbitrary name of the control-plane protocol
+                instance.";
+           }
+           leaf description {
+             type string;
+             description
+               "Textual description of the control-plane protocol
+                instance.";
+           }
+           container static-routes {
+             when "derived-from-or-self(../type, 'rt:static')" {
+               description
+                 "This container is only valid for the 'static' routing
+                  protocol.";
+             }
+             description
+               "Configuration of the 'static' pseudo-protocol.
+
+                Address-family-specific modules augment this node with
+                their lists of routes.";
+           }
+         }
+       }
+       container ribs {
+         description
+           "Configuration of RIBs.";
+         list rib {
+           key "name";
+           description
+             "Each entry contains configuration for a RIB identified by
+              the 'name' key.
+
+              Entries having the same key as a system-controlled entry
+              of the list /routing-state/ribs/rib are used for
+              configuring parameters of that entry.  Other entries
+              define additional user-controlled RIBs.";
+           leaf name {
+             type string;
+             description
+               "The name of the RIB.
+
+                For system-controlled entries, the value of this leaf
+                must be the same as the name of the corresponding entry
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 25]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+                in state data.
+
+                For user-controlled entries, an arbitrary name can be
+                used.";
+           }
+           uses address-family {
+             description
+               "Address family of the RIB.
+
+                It is mandatory for user-controlled RIBs.  For
+                system-controlled RIBs it can be omitted; otherwise, it
+                must match the address family of the corresponding state
+                entry.";
+             refine "address-family" {
+               mandatory "false";
+             }
+           }
+           leaf description {
+             type string;
+             description
+               "Textual description of the RIB.";
+           }
+         }
+       }
+     }
+   }
+
+   <CODE ENDS>
+
+8.  IPv4 Unicast Routing Management YANG Module
+
+   <CODE BEGINS> file "ietf-ipv4-unicast-routing@2016-11-04.yang"
+
+   module ietf-ipv4-unicast-routing {
+
+     yang-version "1.1";
+
+     namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing";
+
+     prefix "v4ur";
+
+     import ietf-routing {
+       prefix "rt";
+     }
+
+     import ietf-inet-types {
+       prefix "inet";
+     }
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 26]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+     organization
+       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
+
+     contact
+       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
+        WG List:  <mailto:netmod@ietf.org>
+
+        WG Chair: Lou Berger
+                  <mailto:lberger@labn.net>
+
+        WG Chair: Kent Watsen
+                  <mailto:kwatsen@juniper.net>
+
+        Editor:   Ladislav Lhotka
+                  <mailto:lhotka@nic.cz>
+
+        Editor:   Acee Lindem
+                  <mailto:acee@cisco.com>";
+
+     description
+       "This YANG module augments the 'ietf-routing' module with basic
+        configuration and state data for IPv4 unicast routing.
+
+        Copyright (c) 2016 IETF Trust and the persons identified as
+        authors of the code.  All rights reserved.
+
+        Redistribution and use in source and binary forms, with or
+        without modification, is permitted pursuant to, and subject to
+        the license terms contained in, the Simplified BSD License set
+        forth in Section 4.c of the IETF Trust's Legal Provisions
+        Relating to IETF Documents
+        (http://trustee.ietf.org/license-info).
+
+        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
+        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
+        'OPTIONAL' in the module text are to be interpreted as described
+        in RFC 2119.
+
+        This version of this YANG module is part of RFC 8022;
+        see the RFC itself for full legal notices.";
+
+     revision 2016-11-04 {
+       description
+         "Initial revision.";
+       reference
+         "RFC 8022: A YANG Data Model for Routing Management";
+     }
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 27]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+     /* Identities */
+
+     identity ipv4-unicast {
+       base rt:ipv4;
+       description
+         "This identity represents the IPv4 unicast address family.";
+     }
+
+     /* State data */
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" {
+       when "derived-from-or-self(../../rt:address-family, "
+          + "'v4ur:ipv4-unicast')" {
+         description
+           "This augment is valid only for IPv4 unicast.";
+       }
+       description
+         "This leaf augments an IPv4 unicast route.";
+       leaf destination-prefix {
+         type inet:ipv4-prefix;
+         description
+           "IPv4 destination prefix.";
+       }
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
+           + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
+       when "derived-from-or-self(../../../rt:address-family, "
+          + "'v4ur:ipv4-unicast')" {
+         description
+           "This augment is valid only for IPv4 unicast.";
+       }
+       description
+         "Augment 'simple-next-hop' case in IPv4 unicast routes.";
+       leaf next-hop-address {
+         type inet:ipv4-address;
+         description
+           "IPv4 address of the next hop.";
+       }
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
+           + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
+           + "rt:next-hop-list/rt:next-hop" {
+       when "derived-from-or-self(../../../../../rt:address-family, "
+          + "'v4ur:ipv4-unicast')" {
+         description
+           "This augment is valid only for IPv4 unicast.";
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 28]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+       }
+       description
+         "This leaf augments the 'next-hop-list' case of IPv4 unicast
+          routes.";
+       leaf address {
+         type inet:ipv4-address;
+         description
+           "IPv4 address of the next-hop.";
+       }
+     }
+
+     augment
+       "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" {
+       when "derived-from-or-self(../rt:address-family, "
+          + "'v4ur:ipv4-unicast')" {
+         description
+           "This augment is valid only for IPv4 unicast RIBs.";
+       }
+       description
+         "This augment adds the input parameter of the 'active-route'
+          action.";
+       leaf destination-address {
+         type inet:ipv4-address;
+         description
+           "IPv4 destination address.";
+       }
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+           + "rt:output/rt:route" {
+       when "derived-from-or-self(../../rt:address-family, "
+          + "'v4ur:ipv4-unicast')" {
+         description
+           "This augment is valid only for IPv4 unicast.";
+       }
+       description
+         "This augment adds the destination prefix to the reply of the
+          'active-route' action.";
+       leaf destination-prefix {
+         type inet:ipv4-prefix;
+         description
+           "IPv4 destination prefix.";
+       }
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+           + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+           + "rt:simple-next-hop" {
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 29]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+       when "derived-from-or-self(../../../rt:address-family, "
+          + "'v4ur:ipv4-unicast')" {
+         description
+           "This augment is valid only for IPv4 unicast.";
+       }
+       description
+         "Augment 'simple-next-hop' case in the reply to the
+          'active-route' action.";
+       leaf next-hop-address {
+         type inet:ipv4-address;
+         description
+           "IPv4 address of the next hop.";
+       }
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+           + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+           + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
+       when "derived-from-or-self(../../../../../rt:address-family, "
+          + "'v4ur:ipv4-unicast')" {
+         description
+           "This augment is valid only for IPv4 unicast.";
+       }
+       description
+         "Augment 'next-hop-list' case in the reply to the
+          'active-route' action.";
+       leaf next-hop-address {
+         type inet:ipv4-address;
+         description
+           "IPv4 address of the next hop.";
+       }
+     }
+
+     /* Configuration data */
+
+     augment "/rt:routing/rt:control-plane-protocols/"
+           + "rt:control-plane-protocol/rt:static-routes" {
+       description
+         "This augment defines the configuration of the 'static'
+          pseudo-protocol with data specific to IPv4 unicast.";
+       container ipv4 {
+         description
+           "Configuration of a 'static' pseudo-protocol instance
+            consists of a list of routes.";
+         list route {
+           key "destination-prefix";
+           description
+             "A list of static routes.";
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 30]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+           leaf destination-prefix {
+             type inet:ipv4-prefix;
+             mandatory "true";
+             description
+               "IPv4 destination prefix.";
+           }
+           leaf description {
+             type string;
+             description
+               "Textual description of the route.";
+           }
+           container next-hop {
+             description
+               "Configuration of next-hop.";
+             uses rt:next-hop-content {
+               augment "next-hop-options/simple-next-hop" {
+                 description
+                   "Augment 'simple-next-hop' case in IPv4 static
+                    routes.";
+                 leaf next-hop-address {
+                   type inet:ipv4-address;
+                   description
+                     "IPv4 address of the next hop.";
+                 }
+               }
+               augment "next-hop-options/next-hop-list/next-hop-list/"
+                     + "next-hop" {
+                 description
+                   "Augment 'next-hop-list' case in IPv4 static
+                    routes.";
+                 leaf next-hop-address {
+                   type inet:ipv4-address;
+                   description
+                     "IPv4 address of the next hop.";
+                 }
+               }
+             }
+           }
+         }
+       }
+     }
+   }
+
+   <CODE ENDS>
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 31]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+9.  IPv6 Unicast Routing Management YANG Module
+
+   <CODE BEGINS> file "ietf-ipv6-unicast-routing@2016-11-04.yang"
+
+   module ietf-ipv6-unicast-routing {
+
+     yang-version "1.1";
+
+     namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing";
+
+     prefix "v6ur";
+
+     import ietf-routing {
+       prefix "rt";
+     }
+
+     import ietf-inet-types {
+       prefix "inet";
+     }
+
+     include ietf-ipv6-router-advertisements {
+       revision-date 2016-11-04;
+     }
+
+     organization
+       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
+
+     contact
+       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
+        WG List:  <mailto:netmod@ietf.org>
+
+        WG Chair: Lou Berger
+                  <mailto:lberger@labn.net>
+
+        WG Chair: Kent Watsen
+                  <mailto:kwatsen@juniper.net>
+
+        Editor:   Ladislav Lhotka
+                  <mailto:lhotka@nic.cz>
+
+        Editor:   Acee Lindem
+                  <mailto:acee@cisco.com>";
+
+     description
+       "This YANG module augments the 'ietf-routing' module with basic
+        configuration and state data for IPv6 unicast routing.
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 32]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+        Copyright (c) 2016 IETF Trust and the persons identified as
+        authors of the code.  All rights reserved.
+
+        Redistribution and use in source and binary forms, with or
+        without modification, is permitted pursuant to, and subject to
+        the license terms contained in, the Simplified BSD License set
+        forth in Section 4.c of the IETF Trust's Legal Provisions
+        Relating to IETF Documents
+        (http://trustee.ietf.org/license-info).
+
+        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
+        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
+        'OPTIONAL' in the module text are to be interpreted as described
+        in RFC 2119.
+
+        This version of this YANG module is part of RFC 8022;
+        see the RFC itself for full legal notices.";
+
+     revision 2016-11-04 {
+       description
+         "Initial revision.";
+       reference
+         "RFC 8022: A YANG Data Model for Routing Management";
+     }
+
+     /* Identities */
+
+     identity ipv6-unicast {
+       base rt:ipv6;
+       description
+         "This identity represents the IPv6 unicast address family.";
+     }
+
+     /* State data */
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" {
+       when "derived-from-or-self(../../rt:address-family, "
+          + "'v6ur:ipv6-unicast')" {
+         description
+           "This augment is valid only for IPv6 unicast.";
+       }
+       description
+         "This leaf augments an IPv6 unicast route.";
+       leaf destination-prefix {
+         type inet:ipv6-prefix;
+         description
+           "IPv6 destination prefix.";
+       }
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 33]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
+           + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
+       when "derived-from-or-self(../../../rt:address-family, "
+          + "'v6ur:ipv6-unicast')" {
+         description
+           "This augment is valid only for IPv6 unicast.";
+       }
+       description
+         "Augment 'simple-next-hop' case in IPv6 unicast routes.";
+       leaf next-hop-address {
+         type inet:ipv6-address;
+         description
+           "IPv6 address of the next hop.";
+       }
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
+           + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
+           + "rt:next-hop-list/rt:next-hop" {
+       when "derived-from-or-self(../../../../../rt:address-family, "
+          + "'v6ur:ipv6-unicast')" {
+         description
+           "This augment is valid only for IPv6 unicast.";
+       }
+       description
+         "This leaf augments the 'next-hop-list' case of IPv6 unicast
+          routes.";
+       leaf address {
+         type inet:ipv6-address;
+         description
+           "IPv6 address of the next hop.";
+       }
+     }
+
+     augment
+       "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" {
+       when "derived-from-or-self(../rt:address-family, "
+          + "'v6ur:ipv6-unicast')" {
+         description
+           "This augment is valid only for IPv6 unicast RIBs.";
+       }
+       description
+         "This augment adds the input parameter of the 'active-route'
+          action.";
+       leaf destination-address {
+         type inet:ipv6-address;
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 34]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+         description
+           "IPv6 destination address.";
+       }
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+           + "rt:output/rt:route" {
+       when "derived-from-or-self(../../rt:address-family, "
+          + "'v6ur:ipv6-unicast')" {
+         description
+           "This augment is valid only for IPv6 unicast.";
+       }
+       description
+         "This augment adds the destination prefix to the reply of the
+          'active-route' action.";
+       leaf destination-prefix {
+         type inet:ipv6-prefix;
+         description
+           "IPv6 destination prefix.";
+       }
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+           + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+           + "rt:simple-next-hop" {
+       when "derived-from-or-self(../../../rt:address-family, "
+          + "'v6ur:ipv6-unicast')" {
+         description
+           "This augment is valid only for IPv6 unicast.";
+       }
+       description
+         "Augment 'simple-next-hop' case in the reply to the
+          'active-route' action.";
+       leaf next-hop-address {
+         type inet:ipv6-address;
+         description
+           "IPv6 address of the next hop.";
+       }
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+           + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+           + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
+       when "derived-from-or-self(../../../../../rt:address-family, "
+          + "'v6ur:ipv6-unicast')" {
+         description
+           "This augment is valid only for IPv6 unicast.";
+       }
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 35]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+       description
+         "Augment 'next-hop-list' case in the reply to the
+          'active-route' action.";
+       leaf next-hop-address {
+         type inet:ipv6-address;
+         description
+           "IPv6 address of the next hop.";
+       }
+     }
+
+     /* Configuration data */
+
+     augment "/rt:routing/rt:control-plane-protocols/"
+           + "rt:control-plane-protocol/rt:static-routes" {
+       description
+         "This augment defines the configuration of the 'static'
+          pseudo-protocol with data specific to IPv6 unicast.";
+       container ipv6 {
+         description
+           "Configuration of a 'static' pseudo-protocol instance
+            consists of a list of routes.";
+         list route {
+           key "destination-prefix";
+           description
+             "A list of static routes.";
+           leaf destination-prefix {
+             type inet:ipv6-prefix;
+             mandatory "true";
+             description
+               "IPv6 destination prefix.";
+           }
+           leaf description {
+             type string;
+             description
+               "Textual description of the route.";
+           }
+           container next-hop {
+             description
+               "Configuration of next-hop.";
+             uses rt:next-hop-content {
+               augment "next-hop-options/simple-next-hop" {
+                 description
+                   "Augment 'simple-next-hop' case in IPv6 static
+                    routes.";
+                 leaf next-hop-address {
+                   type inet:ipv6-address;
+                   description
+                     "IPv6 address of the next hop.";
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 36]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+                 }
+               }
+               augment "next-hop-options/next-hop-list/next-hop-list/"
+                     + "next-hop" {
+                 description
+                   "Augment 'next-hop-list' case in IPv6 static
+                    routes.";
+                 leaf next-hop-address {
+                   type inet:ipv6-address;
+                   description
+                     "IPv6 address of the next hop.";
+                 }
+               }
+             }
+           }
+         }
+       }
+     }
+   }
+
+   <CODE ENDS>
+
+9.1.  IPv6 Router Advertisements Submodule
+
+   <CODE BEGINS> file "ietf-ipv6-router-advertisements@2016-11-04.yang"
+
+   submodule ietf-ipv6-router-advertisements {
+
+     yang-version "1.1";
+
+     belongs-to ietf-ipv6-unicast-routing {
+       prefix "v6ur";
+     }
+
+     import ietf-inet-types {
+       prefix "inet";
+     }
+
+     import ietf-interfaces {
+       prefix "if";
+     }
+
+     import ietf-ip {
+       prefix "ip";
+     }
+
+     organization
+       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 37]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+     contact
+       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
+        WG List:  <mailto:netmod@ietf.org>
+
+        WG Chair: Lou Berger
+                  <mailto:lberger@labn.net>
+
+        WG Chair: Kent Watsen
+                  <mailto:kwatsen@juniper.net>
+
+        Editor:   Ladislav Lhotka
+                  <mailto:lhotka@nic.cz>
+
+        Editor:   Acee Lindem
+                  <mailto:acee@cisco.com>";
+
+     description
+       "This YANG module augments the 'ietf-ip' module with
+        configuration and state data of IPv6 router advertisements.
+
+        Copyright (c) 2016 IETF Trust and the persons identified as
+        authors of the code.  All rights reserved.
+
+        Redistribution and use in source and binary forms, with or
+        without modification, is permitted pursuant to, and subject to
+        the license terms contained in, the Simplified BSD License set
+        forth in Section 4.c of the IETF Trust's Legal Provisions
+        Relating to IETF Documents
+        (http://trustee.ietf.org/license-info).
+
+        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
+        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
+        'OPTIONAL' in the module text are to be interpreted as described
+        in RFC 2119.
+
+        This version of this YANG module is part of RFC 8022;
+        see the RFC itself for full legal notices.";
+
+     reference
+       "RFC 4861: Neighbor Discovery for IP version 6 (IPv6).";
+
+     revision 2016-11-04 {
+       description
+         "Initial revision.";
+       reference
+         "RFC 8022: A YANG Data Model for Routing Management";
+     }
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 38]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+     /* State data */
+
+     augment "/if:interfaces-state/if:interface/ip:ipv6" {
+       description
+         "Augment interface state data with parameters of IPv6 router
+          advertisements.";
+       container ipv6-router-advertisements {
+         description
+           "Parameters of IPv6 Router Advertisements.";
+         leaf send-advertisements {
+           type boolean;
+           description
+             "A flag indicating whether or not the router sends periodic
+              Router Advertisements and responds to Router
+              Solicitations.";
+         }
+         leaf max-rtr-adv-interval {
+           type uint16 {
+             range "4..1800";
+           }
+           units "seconds";
+           description
+             "The maximum time allowed between sending unsolicited
+              multicast Router Advertisements from the interface.";
+         }
+         leaf min-rtr-adv-interval {
+           type uint16 {
+             range "3..1350";
+           }
+           units "seconds";
+           description
+             "The minimum time allowed between sending unsolicited
+              multicast Router Advertisements from the interface.";
+         }
+         leaf managed-flag {
+           type boolean;
+           description
+             "The value that is placed in the 'Managed address
+              configuration' flag field in the Router Advertisement.";
+         }
+         leaf other-config-flag {
+           type boolean;
+           description
+             "The value that is placed in the 'Other configuration' flag
+              field in the Router Advertisement.";
+         }
+         leaf link-mtu {
+           type uint32;
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 39]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+           description
+             "The value that is placed in MTU options sent by the
+              router.  A value of zero indicates that no MTU options are
+              sent.";
+         }
+         leaf reachable-time {
+           type uint32 {
+             range "0..3600000";
+           }
+           units "milliseconds";
+           description
+             "The value that is placed in the Reachable Time field in
+              the Router Advertisement messages sent by the router.  A
+              value of zero means unspecified (by this router).";
+         }
+         leaf retrans-timer {
+           type uint32;
+           units "milliseconds";
+           description
+             "The value that is placed in the Retrans Timer field in the
+              Router Advertisement messages sent by the router.  A value
+              of zero means unspecified (by this router).";
+         }
+
+         leaf cur-hop-limit {
+           type uint8;
+           description
+             "The value that is placed in the Cur Hop Limit field in the
+              Router Advertisement messages sent by the router.  A value
+              of zero means unspecified (by this router).";
+         }
+         leaf default-lifetime {
+           type uint16 {
+             range "0..9000";
+           }
+           units "seconds";
+           description
+             "The value that is placed in the Router Lifetime field of
+              Router Advertisements sent from the interface, in seconds.
+              A value of zero indicates that the router is not to be
+              used as a default router.";
+         }
+         container prefix-list {
+           description
+             "A list of prefixes that are placed in Prefix Information
+              options in Router Advertisement messages sent from the
+              interface.
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 40]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+              By default, these are all prefixes that the router
+              advertises via routing protocols as being on-link for the
+              interface from which the advertisement is sent.";
+           list prefix {
+             key "prefix-spec";
+             description
+               "Advertised prefix entry and its parameters.";
+             leaf prefix-spec {
+               type inet:ipv6-prefix;
+               description
+                 "IPv6 address prefix.";
+             }
+             leaf valid-lifetime {
+               type uint32;
+               units "seconds";
+               description
+                 "The value that is placed in the Valid Lifetime in the
+                  Prefix Information option.  The designated value of
+                  all 1's (0xffffffff) represents infinity.
+
+                  An implementation SHOULD keep this value constant in
+                  consecutive advertisements except when it is
+                  explicitly changed in configuration.";
+             }
+             leaf on-link-flag {
+               type boolean;
+               description
+                 "The value that is placed in the on-link flag ('L-bit')
+                  field in the Prefix Information option.";
+             }
+             leaf preferred-lifetime {
+               type uint32;
+               units "seconds";
+               description
+                 "The value that is placed in the Preferred Lifetime in
+                  the Prefix Information option, in seconds.  The
+                  designated value of all 1's (0xffffffff) represents
+                  infinity.
+
+                  An implementation SHOULD keep this value constant in
+                  consecutive advertisements except when it is
+                  explicitly changed in configuration.";
+             }
+             leaf autonomous-flag {
+               type boolean;
+               description
+                 "The value that is placed in the Autonomous Flag field
+                  in the Prefix Information option.";
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 41]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+             }
+           }
+         }
+       }
+     }
+
+     /* Configuration data */
+
+     augment "/if:interfaces/if:interface/ip:ipv6" {
+       description
+         "Augment interface configuration with parameters of IPv6 router
+          advertisements.";
+       container ipv6-router-advertisements {
+         description
+           "Configuration of IPv6 Router Advertisements.";
+         leaf send-advertisements {
+           type boolean;
+           default "false";
+           description
+             "A flag indicating whether or not the router sends periodic
+              Router Advertisements and responds to Router
+              Solicitations.";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              AdvSendAdvertisements.";
+         }
+         leaf max-rtr-adv-interval {
+           type uint16 {
+             range "4..1800";
+           }
+           units "seconds";
+           default "600";
+           description
+             "The maximum time allowed between sending unsolicited
+              multicast Router Advertisements from the interface.";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              MaxRtrAdvInterval.";
+         }
+         leaf min-rtr-adv-interval {
+           type uint16 {
+             range "3..1350";
+           }
+           units "seconds";
+           must ". <= 0.75 * ../max-rtr-adv-interval" {
+             description
+               "The value MUST NOT be greater than 75% of
+                'max-rtr-adv-interval'.";
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 42]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+           }
+           description
+             "The minimum time allowed between sending unsolicited
+              multicast Router Advertisements from the interface.
+
+              The default value to be used operationally if this leaf is
+              not configured is determined as follows:
+
+              - if max-rtr-adv-interval >= 9 seconds, the default
+                value is 0.33 * max-rtr-adv-interval;
+
+              - otherwise, it is 0.75 * max-rtr-adv-interval.";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              MinRtrAdvInterval.";
+         }
+         leaf managed-flag {
+           type boolean;
+           default "false";
+           description
+             "The value to be placed in the 'Managed address
+              configuration' flag field in the Router Advertisement.";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              AdvManagedFlag.";
+         }
+         leaf other-config-flag {
+           type boolean;
+           default "false";
+           description
+             "The value to be placed in the 'Other configuration' flag
+              field in the Router Advertisement.";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              AdvOtherConfigFlag.";
+         }
+         leaf link-mtu {
+           type uint32;
+           default "0";
+           description
+             "The value to be placed in MTU options sent by the router.
+              A value of zero indicates that no MTU options are sent.";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              AdvLinkMTU.";
+         }
+         leaf reachable-time {
+           type uint32 {
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 43]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+             range "0..3600000";
+           }
+           units "milliseconds";
+           default "0";
+           description
+             "The value to be placed in the Reachable Time field in the
+              Router Advertisement messages sent by the router.  A value
+              of zero means unspecified (by this router).";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              AdvReachableTime.";
+         }
+         leaf retrans-timer {
+           type uint32;
+           units "milliseconds";
+           default "0";
+           description
+             "The value to be placed in the Retrans Timer field in the
+              Router Advertisement messages sent by the router.  A value
+              of zero means unspecified (by this router).";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              AdvRetransTimer.";
+         }
+         leaf cur-hop-limit {
+           type uint8;
+           description
+             "The value to be placed in the Cur Hop Limit field in the
+              Router Advertisement messages sent by the router.  A value
+              of zero means unspecified (by this router).
+
+              If this parameter is not configured, the device SHOULD use
+              the value specified in IANA Assigned Numbers that was in
+              effect at the time of implementation.";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              AdvCurHopLimit.
+
+              IANA: IP Parameters,
+              http://www.iana.org/assignments/ip-parameters";
+         }
+         leaf default-lifetime {
+           type uint16 {
+             range "0..9000";
+           }
+           units "seconds";
+           description
+             "The value to be placed in the Router Lifetime field of
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 44]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+              Router Advertisements sent from the interface, in seconds.
+              It MUST be either zero or between max-rtr-adv-interval and
+              9000 seconds.  A value of zero indicates that the router
+              is not to be used as a default router.  These limits may
+              be overridden by specific documents that describe how IPv6
+              operates over different link layers.
+
+              If this parameter is not configured, the device SHOULD use
+              a value of 3 * max-rtr-adv-interval.";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              AdvDefaultLifeTime.";
+         }
+         container prefix-list {
+           description
+             "Configuration of prefixes to be placed in Prefix
+              Information options in Router Advertisement messages sent
+              from the interface.
+
+              Prefixes that are advertised by default but do not have
+              their entries in the child 'prefix' list are advertised
+              with the default values of all parameters.
+
+              The link-local prefix SHOULD NOT be included in the list
+              of advertised prefixes.";
+           reference
+             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) -
+              AdvPrefixList.";
+           list prefix {
+             key "prefix-spec";
+             description
+               "Configuration of an advertised prefix entry.";
+             leaf prefix-spec {
+               type inet:ipv6-prefix;
+               description
+                 "IPv6 address prefix.";
+             }
+             choice control-adv-prefixes {
+               default "advertise";
+               description
+                 "Either the prefix is explicitly removed from the
+                  set of advertised prefixes, or the parameters with
+                  which it is advertised are specified (default case).";
+               leaf no-advertise {
+                 type empty;
+                 description
+                   "The prefix will not be advertised.
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 45]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+                    This can be used for removing the prefix from the
+                    default set of advertised prefixes.";
+               }
+               case advertise {
+                 leaf valid-lifetime {
+                   type uint32;
+                   units "seconds";
+                   default "2592000";
+                   description
+                     "The value to be placed in the Valid Lifetime in
+                      the Prefix Information option.  The designated
+                      value of all 1's (0xffffffff) represents
+                      infinity.";
+                   reference
+                     "RFC 4861: Neighbor Discovery for IP version 6
+                      (IPv6) - AdvValidLifetime.";
+                 }
+                 leaf on-link-flag {
+                   type boolean;
+                   default "true";
+                   description
+                     "The value to be placed in the on-link flag
+                      ('L-bit') field in the Prefix Information
+                      option.";
+                   reference
+                     "RFC 4861: Neighbor Discovery for IP version 6
+                      (IPv6) - AdvOnLinkFlag.";
+                 }
+                 leaf preferred-lifetime {
+                   type uint32;
+                   units "seconds";
+                   must ". <= ../valid-lifetime" {
+                     description
+                       "This value MUST NOT be greater than
+                        valid-lifetime.";
+                   }
+                   default "604800";
+                   description
+                     "The value to be placed in the Preferred Lifetime
+                      in the Prefix Information option.  The designated
+                      value of all 1's (0xffffffff) represents
+                      infinity.";
+                   reference
+                     "RFC 4861: Neighbor Discovery for IP version 6
+                      (IPv6) - AdvPreferredLifetime.";
+                 }
+                 leaf autonomous-flag {
+                   type boolean;
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 46]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+                   default "true";
+                   description
+                     "The value to be placed in the Autonomous Flag
+                      field in the Prefix Information option.";
+                   reference
+                     "RFC 4861: Neighbor Discovery for IP version 6
+                      (IPv6) - AdvAutonomousFlag.";
+                 }
+               }
+             }
+           }
+         }
+       }
+     }
+   }
+
+   <CODE ENDS>
+
+10.  IANA Considerations
+
+   This document registers the following namespace URIs in the "IETF XML
+   Registry" [RFC3688]:
+
+   URI: urn:ietf:params:xml:ns:yang:ietf-routing
+   Registrant Contact: The IESG.
+   XML: N/A; the requested URI is an XML namespace.
+
+   URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing
+   Registrant Contact: The IESG.
+   XML: N/A; the requested URI is an XML namespace.
+
+   URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing
+   Registrant Contact: The IESG.
+   XML: N/A; the requested URI is an XML namespace.
+
+   This document registers the following YANG modules in the "YANG
+   Module Names" registry [RFC6020]:
+
+   Name:         ietf-routing
+   Namespace:    urn:ietf:params:xml:ns:yang:ietf-routing
+   Prefix:       rt
+   Reference:    RFC 8022
+
+   Name:         ietf-ipv4-unicast-routing
+   Namespace:    urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing
+   Prefix:       v4ur
+   Reference:    RFC 8022
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 47]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+   Name:         ietf-ipv6-unicast-routing
+   Namespace:    urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing
+   Prefix:       v6ur
+   Reference:    RFC 8022
+
+   This document registers the following YANG submodule in the "YANG
+   Module Names" registry [RFC6020]:
+
+   Name:         ietf-ipv6-router-advertisements
+   Module:       ietf-ipv6-unicast-routing
+   Reference:    RFC 8022
+
+11.  Security Considerations
+
+   Configuration and state data conforming to the core routing data
+   model (defined in this document) are designed to be accessed via a
+   management protocol with a secure transport layer, such as NETCONF
+   [RFC6241].  The NETCONF access control model [RFC6536] provides the
+   means to restrict access for particular NETCONF users to a
+   preconfigured subset of all available NETCONF protocol operations and
+   content.
+
+   A number of configuration data nodes defined in the YANG modules
+   belonging to the core routing data model are writable/creatable/
+   deletable (i.e., "config true" in YANG terms, which is the default).
+   These data nodes may be considered sensitive or vulnerable in some
+   network environments.  Write operations to these data nodes, such as
+   "edit-config" in NETCONF, can have negative effects on the network if
+   the protocol operations are not properly protected.
+
+   The vulnerable "config true" parameters and subtrees are the
+   following:
+
+   /routing/control-plane-protocols/control-plane-protocol:  This list
+      specifies the control-plane protocols configured on a device.
+
+   /routing/ribs/rib:  This list specifies the RIBs configured for the
+      device.
+
+   Unauthorized access to any of these lists can adversely affect the
+   routing subsystem of both the local device and the network.  This may
+   lead to network malfunctions, delivery of packets to inappropriate
+   destinations, and other problems.
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 48]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              DOI 10.17487/RFC3688, January 2004,
+              <http://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              DOI 10.17487/RFC4861, September 2007,
+              <http://www.rfc-editor.org/info/rfc4861>.
+
+   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+              the Network Configuration Protocol (NETCONF)", RFC 6020,
+              DOI 10.17487/RFC6020, October 2010,
+              <http://www.rfc-editor.org/info/rfc6020>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <http://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
+              RFC 6991, DOI 10.17487/RFC6991, July 2013,
+              <http://www.rfc-editor.org/info/rfc6991>.
+
+   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
+              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
+              <http://www.rfc-editor.org/info/rfc7223>.
+
+   [RFC7277]  Bjorklund, M., "A YANG Data Model for IP Management",
+              RFC 7277, DOI 10.17487/RFC7277, June 2014,
+              <http://www.rfc-editor.org/info/rfc7277>.
+
+   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
+              RFC 7950, DOI 10.17487/RFC7950, August 2016,
+              <http://www.rfc-editor.org/info/rfc7950>.
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 49]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+12.2.  Informative References
+
+   [RFC6087]  Bierman, A., "Guidelines for Authors and Reviewers of YANG
+              Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
+              January 2011, <http://www.rfc-editor.org/info/rfc6087>.
+
+   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
+              Protocol (NETCONF) Access Control Model", RFC 6536,
+              DOI 10.17487/RFC6536, March 2012,
+              <http://www.rfc-editor.org/info/rfc6536>.
+
+   [RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
+              Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
+              <http://www.rfc-editor.org/info/rfc7895>.
+
+   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
+              RFC 7951, DOI 10.17487/RFC7951, August 2016,
+              <http://www.rfc-editor.org/info/rfc7951>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 50]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+Appendix A.  The Complete Data Trees
+
+   This appendix presents the complete configuration and state data
+   trees of the core routing data model.  See Section 2.2 for an
+   explanation of the symbols used.  The data type of every leaf node is
+   shown near the right end of the corresponding line.
+
+A.1.  Configuration Data
+
+   +--rw routing
+      +--rw router-id?                 yang:dotted-quad
+      +--rw control-plane-protocols
+      |  +--rw control-plane-protocol* [type name]
+      |     +--rw type             identityref
+      |     +--rw name             string
+      |     +--rw description?     string
+      |     +--rw static-routes
+      |        +--rw v6ur:ipv6
+      |        |  +--rw v6ur:route* [destination-prefix]
+      |        |     +--rw v6ur:destination-prefix    inet:ipv6-prefix
+      |        |     +--rw v6ur:description?          string
+      |        |     +--rw v6ur:next-hop
+      |        |        +--rw (v6ur:next-hop-options)
+      |        |           +--:(v6ur:simple-next-hop)
+      |        |           |  +--rw v6ur:outgoing-interface?
+      |        |           |  +--rw v6ur:next-hop-address?
+      |        |           +--:(v6ur:special-next-hop)
+      |        |           |  +--rw v6ur:special-next-hop?   enumeration
+      |        |           +--:(v6ur:next-hop-list)
+      |        |              +--rw v6ur:next-hop-list
+      |        |                 +--rw v6ur:next-hop* [index]
+      |        |                    +--rw v6ur:index              string
+      |        |                    +--rw v6ur:outgoing-interface?
+      |        |                    +--rw v6ur:next-hop-address?
+      |        +--rw v4ur:ipv4
+      |           +--rw v4ur:route* [destination-prefix]
+      |              +--rw v4ur:destination-prefix    inet:ipv4-prefix
+      |              +--rw v4ur:description?          string
+      |              +--rw v4ur:next-hop
+      |                 +--rw (v4ur:next-hop-options)
+      |                    +--:(v4ur:simple-next-hop)
+      |                    |  +--rw v4ur:outgoing-interface?
+      |                    |  +--rw v4ur:next-hop-address?
+      |                    +--:(v4ur:special-next-hop)
+      |                    |  +--rw v4ur:special-next-hop?   enumeration
+      |                    +--:(v4ur:next-hop-list)
+      |                       +--rw v4ur:next-hop-list
+      |                          +--rw v4ur:next-hop* [index]
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 51]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+      |                             +--rw v4ur:index              string
+      |                             +--rw v4ur:outgoing-interface?
+      |                             +--rw v4ur:next-hop-address?
+      +--rw ribs
+         +--rw rib* [name]
+            +--rw name              string
+            +--rw address-family?   identityref
+            +--rw description?      string
+
+A.2.  State Data
+
+      +--ro routing-state
+      |  +--ro router-id?                 yang:dotted-quad
+      |  +--ro interfaces
+      |  |  +--ro interface*   if:interface-state-ref
+      |  +--ro control-plane-protocols
+      |  |  +--ro control-plane-protocol* [type name]
+      |  |     +--ro type    identityref
+      |  |     +--ro name    string
+      |  +--ro ribs
+      |     +--ro rib* [name]
+      |        +--ro name              string
+      |        +--ro address-family    identityref
+      |        +--ro default-rib?      boolean {multiple-ribs}?
+      |        +--ro routes
+      |        |  +--ro route*
+      |        |     +--ro route-preference?          route-preference
+      |        |     +--ro next-hop
+      |        |     |  +--ro (next-hop-options)
+      |        |     |     +--:(simple-next-hop)
+      |        |     |     |  +--ro outgoing-interface?
+      |        |     |     |  +--ro v6ur:next-hop-address?
+      |        |     |     |  +--ro v4ur:next-hop-address?
+      |        |     |     +--:(special-next-hop)
+      |        |     |     |  +--ro special-next-hop?        enumeration
+      |        |     |     +--:(next-hop-list)
+      |        |     |        +--ro next-hop-list
+      |        |     |           +--ro next-hop*
+      |        |     |              +--ro outgoing-interface?
+      |        |     |              +--ro v6ur:address?
+      |        |     |              +--ro v4ur:address?
+      |        |     +--ro source-protocol            identityref
+      |        |     +--ro active?                    empty
+      |        |     +--ro last-updated?              yang:date-and-time
+      |        |     +--ro v6ur:destination-prefix?   inet:ipv6-prefix
+      |        |     +--ro v4ur:destination-prefix?   inet:ipv4-prefix
+      |        +---x active-route
+      |           +---w input
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 52]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+      |           |  +---w v6ur:destination-address?   inet:ipv6-address
+      |           |  +---w v4ur:destination-address?   inet:ipv4-address
+      |           +--ro output
+      |              +--ro route
+      |                 +--ro next-hop
+      |                 |  +--ro (next-hop-options)
+      |                 |     +--:(simple-next-hop)
+      |                 |     |  +--ro outgoing-interface?
+      |                 |     |  +--ro v6ur:next-hop-address?
+      |                 |     |  +--ro v4ur:next-hop-address?
+      |                 |     +--:(special-next-hop)
+      |                 |     |  +--ro special-next-hop?     enumeration
+      |                 |     +--:(next-hop-list)
+      |                 |        +--ro next-hop-list
+      |                 |           +--ro next-hop*
+      |                 |              +--ro outgoing-interface?
+      |                 |              +--ro v6ur:next-hop-address?
+      |                 |              +--ro v4ur:next-hop-address?
+      |                 +--ro source-protocol            identityref
+      |                 +--ro active?                    empty
+      |                 +--ro last-updated?           yang:date-and-time
+      |                 +--ro v6ur:destination-prefix?  inet:ipv6-prefix
+      |                 +--ro v4ur:destination-prefix?  inet:ipv4-prefix
+
+Appendix B.  Minimum Implementation
+
+   Some parts and options of the core routing model, such as user-
+   defined RIBs, are intended only for advanced routers.  This appendix
+   gives basic non-normative guidelines for implementing a bare minimum
+   of available functions.  Such an implementation may be used for hosts
+   or very simple routers.
+
+   A minimum implementation does not support the feature
+   "multiple-ribs".  This means that a single system-controlled RIB is
+   available for each supported address family -- IPv4, IPv6, or both.
+   These RIBs are also the default RIBs.  No user-controlled RIBs are
+   allowed.
+
+   In addition to the mandatory instance of the "direct" pseudo-
+   protocol, a minimum implementation should support configuring
+   instance(s) of the "static" pseudo-protocol.
+
+   For hosts that are never intended to act as routers, the ability to
+   turn on sending IPv6 router advertisements (Section 5.4) should be
+   removed.
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 53]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+   Platforms with severely constrained resources may use deviations for
+   restricting the data model, e.g., limiting the number of "static"
+   control-plane protocol instances.
+
+Appendix C.  Example: Adding a New Control-Plane Protocol
+
+   This appendix demonstrates how the core routing data model can be
+   extended to support a new control-plane protocol.  The YANG module
+   "example-rip" shown below is intended as an illustration rather than
+   a real definition of a data model for the Routing Information
+   Protocol (RIP).  For the sake of brevity, this module does not obey
+   all the guidelines specified in [RFC6087].  See also Section 5.3.2.
+
+   module example-rip {
+
+     yang-version "1.1";
+
+     namespace "http://example.com/rip";
+
+     prefix "rip";
+
+     import ietf-interfaces {
+       prefix "if";
+     }
+
+     import ietf-routing {
+       prefix "rt";
+     }
+
+     identity rip {
+       base rt:routing-protocol;
+       description
+         "Identity for the Routing Information Protocol (RIP).";
+     }
+
+     typedef rip-metric {
+       type uint8 {
+         range "0..16";
+       }
+     }
+
+     grouping route-content {
+       description
+         "This grouping defines RIP-specific route attributes.";
+       leaf metric {
+         type rip-metric;
+       }
+       leaf tag {
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 54]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+         type uint16;
+         default "0";
+         description
+           "This leaf may be used to carry additional info, e.g.,
+            autonomous system (AS) number.";
+       }
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" {
+       when "derived-from-or-self(rt:source-protocol, 'rip:rip')" {
+         description
+           "This augment is only valid for a route whose source
+            protocol is RIP.";
+       }
+       description
+         "RIP-specific route attributes.";
+       uses route-content;
+     }
+
+     augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+           + "rt:output/rt:route" {
+       description
+         "RIP-specific route attributes in the output of 'active-route'
+          RPC.";
+       uses route-content;
+     }
+
+     augment "/rt:routing/rt:control-plane-protocols/"
+           + "rt:control-plane-protocol" {
+       when "derived-from-or-self(rt:type,'rip:rip')" {
+         description
+           "This augment is only valid for a routing protocol instance
+            of type 'rip'.";
+       }
+       container rip {
+         presence "RIP configuration";
+         description
+           "RIP instance configuration.";
+         container interfaces {
+           description
+             "Per-interface RIP configuration.";
+           list interface {
+             key "name";
+             description
+               "RIP is enabled on interfaces that have an entry in this
+                list, unless 'enabled' is set to 'false' for that
+                entry.";
+             leaf name {
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 55]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+               type if:interface-ref;
+             }
+             leaf enabled {
+               type boolean;
+               default "true";
+             }
+             leaf metric {
+               type rip-metric;
+               default "1";
+             }
+           }
+         }
+         leaf update-interval {
+           type uint8 {
+             range "10..60";
+           }
+           units "seconds";
+           default "30";
+           description
+             "Time interval between periodic updates.";
+         }
+       }
+     }
+   }
+
+Appendix D.  Data Tree Example
+
+   This section contains an example of an instance data tree in the JSON
+   encoding [RFC7951], containing both configuration and state data.
+   The data conforms to a data model that is defined by the following
+   YANG library specification [RFC7895]:
+
+   {
+     "ietf-yang-library:modules-state": {
+       "module-set-id": "c2e1f54169aa7f36e1a6e8d0865d441d3600f9c4",
+       "module": [
+         {
+           "name": "ietf-routing",
+           "revision": "2016-11-04",
+           "feature": [
+             "multiple-ribs",
+             "router-id"
+           ],
+           "namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
+           "conformance-type": "implement"
+         },
+         {
+           "name": "ietf-ipv4-unicast-routing",
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 56]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+           "revision": "2016-11-04",
+           "namespace":
+             "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing",
+           "conformance-type": "implement"
+         },
+         {
+           "name": "ietf-ipv6-unicast-routing",
+           "revision": "2016-11-04",
+           "namespace":
+             "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing",
+           "conformance-type": "implement"
+         },
+         {
+           "name": "ietf-interfaces",
+           "revision": "2014-05-08",
+           "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
+           "conformance-type": "implement"
+         },
+         {
+           "name": "ietf-inet-types",
+           "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
+           "revision": "2013-07-15",
+           "conformance-type": "import"
+         },
+         {
+           "name": "ietf-yang-types",
+           "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
+           "revision": "2013-07-15",
+           "conformance-type": "import"
+         },
+         {
+           "name": "iana-if-type",
+           "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
+           "revision": "",
+           "conformance-type": "implement"
+         },
+         {
+           "name": "ietf-ip",
+           "revision": "2014-06-16",
+           "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
+           "conformance-type": "implement"
+         }
+       ]
+     }
+   }
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 57]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+   A simple network setup as shown in Figure 3 is assumed: router "A"
+   uses static default routes with the "ISP" router as the next hop.
+   IPv6 router advertisements are configured only on the "eth1"
+   interface and disabled on the upstream "eth0" interface.
+
+                   +-----------------+
+                   |                 |
+                   |    Router ISP   |
+                   |                 |
+                   +--------+--------+
+                            |2001:db8:0:1::2
+                            |192.0.2.2
+                            |
+                            |
+                            |2001:db8:0:1::1
+                        eth0|192.0.2.1
+                   +--------+--------+
+                   |                 |
+                   |     Router A    |
+                   |                 |
+                   +--------+--------+
+                        eth1|198.51.100.1
+                            |2001:db8:0:2::1
+                            |
+
+                Figure 3: Example of Network Configuration
+
+   The instance data tree could then be as follows:
+
+   {
+     "ietf-interfaces:interfaces": {
+       "interface": [
+         {
+           "name": "eth0",
+           "type": "iana-if-type:ethernetCsmacd",
+           "description": "Uplink to ISP.",
+           "ietf-ip:ipv4": {
+             "address": [
+               {
+                 "ip": "192.0.2.1",
+                 "prefix-length": 24
+               }
+             ],
+             "forwarding": true
+           },
+           "ietf-ip:ipv6": {
+             "address": [
+               {
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 58]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+                 "ip": "2001:0db8:0:1::1",
+                 "prefix-length": 64
+               }
+             ],
+             "forwarding": true,
+             "autoconf": {
+               "create-global-addresses": false
+             }
+           }
+         },
+         {
+           "name": "eth1",
+           "type": "iana-if-type:ethernetCsmacd",
+           "description": "Interface to the internal network.",
+           "ietf-ip:ipv4": {
+             "address": [
+               {
+                 "ip": "198.51.100.1",
+                 "prefix-length": 24
+               }
+             ],
+             "forwarding": true
+           },
+           "ietf-ip:ipv6": {
+             "address": [
+               {
+                 "ip": "2001:0db8:0:2::1",
+                 "prefix-length": 64
+               }
+             ],
+             "forwarding": true,
+             "autoconf": {
+               "create-global-addresses": false
+             },
+             "ietf-ipv6-unicast-routing:ipv6-router-advertisements": {
+               "send-advertisements": true
+             }
+           }
+         }
+       ]
+     },
+     "ietf-interfaces:interfaces-state": {
+       "interface": [
+         {
+           "name": "eth0",
+           "type": "iana-if-type:ethernetCsmacd",
+           "phys-address": "00:0C:42:E5:B1:E9",
+           "oper-status": "up",
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 59]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+           "statistics": {
+             "discontinuity-time": "2015-10-24T17:11:27+02:00"
+           },
+           "ietf-ip:ipv4": {
+             "forwarding": true,
+             "mtu": 1500,
+             "address": [
+               {
+                 "ip": "192.0.2.1",
+                 "prefix-length": 24
+               }
+             ]
+           },
+           "ietf-ip:ipv6": {
+             "forwarding": true,
+             "mtu": 1500,
+             "address": [
+               {
+                 "ip": "2001:0db8:0:1::1",
+                 "prefix-length": 64
+               }
+             ],
+             "ietf-ipv6-unicast-routing:ipv6-router-advertisements": {
+               "send-advertisements": false
+             }
+           }
+         },
+         {
+           "name": "eth1",
+           "type": "iana-if-type:ethernetCsmacd",
+           "phys-address": "00:0C:42:E5:B1:EA",
+           "oper-status": "up",
+           "statistics": {
+             "discontinuity-time": "2015-10-24T17:11:29+02:00"
+           },
+           "ietf-ip:ipv4": {
+             "forwarding": true,
+             "mtu": 1500,
+             "address": [
+               {
+                 "ip": "198.51.100.1",
+                 "prefix-length": 24
+               }
+             ]
+           },
+           "ietf-ip:ipv6": {
+             "forwarding": true,
+             "mtu": 1500,
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 60]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+             "address": [
+               {
+                 "ip": "2001:0db8:0:2::1",
+                 "prefix-length": 64
+               }
+             ],
+             "ietf-ipv6-unicast-routing:ipv6-router-advertisements": {
+               "send-advertisements": true,
+               "prefix-list": {
+                 "prefix": [
+                   {
+                     "prefix-spec": "2001:db8:0:2::/64"
+                   }
+                 ]
+               }
+             }
+           }
+         }
+       ]
+     },
+     "ietf-routing:routing": {
+       "router-id": "192.0.2.1",
+       "control-plane-protocols": {
+         "control-plane-protocol": [
+           {
+             "type": "ietf-routing:static",
+             "name": "st0",
+             "description":
+               "Static routing is used for the internal network.",
+             "static-routes": {
+               "ietf-ipv4-unicast-routing:ipv4": {
+                 "route": [
+                   {
+                     "destination-prefix": "0.0.0.0/0",
+                     "next-hop": {
+                       "next-hop-address": "192.0.2.2"
+                     }
+                   }
+                 ]
+               },
+               "ietf-ipv6-unicast-routing:ipv6": {
+                 "route": [
+                   {
+                     "destination-prefix": "::/0",
+                     "next-hop": {
+                       "next-hop-address": "2001:db8:0:1::2"
+                     }
+                   }
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 61]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+                 ]
+               }
+             }
+           }
+         ]
+       }
+     },
+     "ietf-routing:routing-state": {
+       "interfaces": {
+         "interface": [
+           "eth0",
+           "eth1"
+         ]
+       },
+       "control-plane-protocols": {
+         "control-plane-protocol": [
+           {
+             "type": "ietf-routing:static",
+             "name": "st0"
+           }
+         ]
+       },
+       "ribs": {
+         "rib": [
+           {
+             "name": "ipv4-master",
+             "address-family":
+               "ietf-ipv4-unicast-routing:ipv4-unicast",
+             "default-rib": true,
+             "routes": {
+               "route": [
+                 {
+                   "ietf-ipv4-unicast-routing:destination-prefix":
+                     "192.0.2.1/24",
+                   "next-hop": {
+                     "outgoing-interface": "eth0"
+                   },
+                   "route-preference": 0,
+                   "source-protocol": "ietf-routing:direct",
+                   "last-updated": "2015-10-24T17:11:27+02:00"
+                 },
+                 {
+                   "ietf-ipv4-unicast-routing:destination-prefix":
+                     "198.51.100.0/24",
+                   "next-hop": {
+                     "outgoing-interface": "eth1"
+                   },
+                   "source-protocol": "ietf-routing:direct",
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 62]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+                   "route-preference": 0,
+                   "last-updated": "2015-10-24T17:11:27+02:00"
+                 },
+                 {
+                   "ietf-ipv4-unicast-routing:destination-prefix":
+                     "0.0.0.0/0",
+                   "source-protocol": "ietf-routing:static",
+                   "route-preference": 5,
+                   "next-hop": {
+                     "ietf-ipv4-unicast-routing:next-hop-address":
+                       "192.0.2.2"
+                   },
+                   "last-updated": "2015-10-24T18:02:45+02:00"
+                 }
+               ]
+             }
+           },
+           {
+             "name": "ipv6-master",
+             "address-family":
+               "ietf-ipv6-unicast-routing:ipv6-unicast",
+             "default-rib": true,
+             "routes": {
+               "route": [
+                 {
+                   "ietf-ipv6-unicast-routing:destination-prefix":
+                     "2001:db8:0:1::/64",
+                   "next-hop": {
+                     "outgoing-interface": "eth0"
+                   },
+                   "source-protocol": "ietf-routing:direct",
+                   "route-preference": 0,
+                   "last-updated": "2015-10-24T17:11:27+02:00"
+                 },
+                 {
+                   "ietf-ipv6-unicast-routing:destination-prefix":
+                     "2001:db8:0:2::/64",
+                   "next-hop": {
+                     "outgoing-interface": "eth1"
+                   },
+                   "source-protocol": "ietf-routing:direct",
+                   "route-preference": 0,
+                   "last-updated": "2015-10-24T17:11:27+02:00"
+                 },
+                 {
+                   "ietf-ipv6-unicast-routing:destination-prefix":
+                     "::/0",
+                   "next-hop": {
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 63]
+
+RFC 8022                 YANG Routing Management           November 2016
+
+
+                     "ietf-ipv6-unicast-routing:next-hop-address":
+                       "2001:db8:0:1::2"
+                   },
+                   "source-protocol": "ietf-routing:static",
+                   "route-preference": 5,
+                   "last-updated": "2015-10-24T18:02:45+02:00"
+                 }
+               ]
+             }
+           }
+         ]
+       }
+     }
+   }
+
+Acknowledgments
+
+   The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean
+   Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini,
+   David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane
+   Litkowski, Thomas Morin, Tom Petch, Yingzhen Qu, Bruno Rijsman,
+   Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang,
+   Derek Man-Kit Yeung, and Jeffrey Zhang for their helpful comments and
+   suggestions.
+
+Authors' Addresses
+
+   Ladislav Lhotka
+   CZ.NIC
+
+   Email: lhotka@nic.cz
+
+
+   Acee Lindem
+   Cisco Systems
+
+   Email: acee@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka & Lindem              Standards Track                   [Page 64]
+