RFC 8349
A YANG Data Model for Routing Management (NMDA Version)
RFC 8349 (part 1 of 13) 🎀✨
okay bestie, welcome to the core routing data model era 💅🌸 this one's a YANG data model for routing management, the NMDA version, and it's giving "let's build the foundation everything else gets stacked on" 🧱💖
Here's the title-block tea ☕ It's from the IETF, published as an RFC numbered 8349, and it's titled A YANG Data Model for Routing Management (NMDA Version). The authors are L. Lhotka (CZ.NIC), A. Lindem (Cisco Systems), and Y. Qu (Huawei), and it's dated March 2018. The category is Standards Track 🦋, and the ISSN is 2070-1721.
The obsoletes part is the main drama 👑: this doc replaces RFC 8022. It doesn't update anything, it just takes over 😤💅
Abstract 💖
Okay so the abstract says this doc specifies three YANG modules and one submodule 🎀 Together they're the core routing data model, a framework for configuring and managing a routing subsystem. The plan is that other modules will augment them later, for control-plane protocols, route filters, and other functions 🧩 The core model gives everyone shared building blocks: routes, Routing Information Bases (RIBs), and control-plane protocols 🌈
The YANG modules here follow the Network Management Datastore Architecture (NMDA), and this document obsoletes RFC 8022 🙈 bestie, that's the whole glow-up ✨
Status of This Memo 🌸
This is an Internet Standards Track document 🔥 It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841.
Current status, errata, and feedback can be found at https://www.rfc-editor.org/info/rfc8349 🫶
Copyright Notice 💜
Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication. Please review those carefully, since they describe your rights and restrictions. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license 📜✨
Heads up, this is legal stuff, but it matters if you copy code out of here 🙈
Table of Contents 🎀
I'm keeping the TOC in its original shape so the section refs still match 💅
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4
2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 5
2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6
3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. The Design of the Core Routing Data Model . . . . . . . . . . 7
4.1. System-Controlled and User-Controlled List Entries . . . 8
5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 9
5.1. Routes . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Routing Information Base (RIB) . . . . . . . . . . . . . 10
5.3. Control-Plane Protocol . . . . . . . . . . . . . . . . . 11
5.3.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 11
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" . . . . . . . . . . . . . . . . . . . . 14
7. Routing Management YANG Module . . . . . . . . . . . . . . . 15
8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 29
9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 37
9.1. IPv6 Router Advertisements Submodule . . . . . . . . . . 45
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
11. Security Considerations . . . . . . . . . . . . . . . . . . . 57
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
12.1. Normative References . . . . . . . . . . . . . . . . . . 58
12.2. Informative References . . . . . . . . . . . . . . . . . 60
Appendix A. The Complete Schema Tree . . . . . . . . . . . . . . 61
Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 66
Appendix C. Example: Adding a New Control-Plane Protocol . . . . 67
Appendix D. Data Tree Example . . . . . . . . . . . . . . . . . 70
Appendix E. NETCONF Get Data Reply Example . . . . . . . . . . . 77
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 801. Introduction ✨
Okay, so this section lists the YANG modules 🎀
- "ietf-routing" gives you the generic components of a routing data model 🧚
- "ietf-ipv4-unicast-routing" augments "ietf-routing" with IPv4 unicast stuff 💖
- "ietf-ipv6-unicast-routing" augments "ietf-routing" with IPv6 unicast stuff. Its submodule, "ietf-ipv6-router-advertisements", also augments "ietf-interfaces" [RFC8343] and "ietf-ip" [RFC8344] with IPv6 router config variables that [RFC4861] requires 🦋
All three together are the core routing data model, which is meant to be a base for future data model work on more-sophisticated routing systems 💅 You can use these three straight up for simple IP devices with static routing (see Appendix B) 🌸 But the real point is building blocks for fancier stuff: multiple control-plane protocols, multicast routing, extra address families, and advanced functions like route filtering or policy routing 🔥 So it's expected that working groups will augment this core with tons of modules 🫶
The YANG modules here conform to the NMDA [RFC8342], and this document obsoletes RFC 8022 [RFC8022] 👑
2. Terminology and Notation 💜
Here's the key-word situation 🎀 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in ALL CAPS, like shown here 🙈 Otherwise they're just regular words, bestie.
The following terms come from [RFC8342]:
- client
- server
- configuration
- system state
- operational state
- intended configuration
The following terms come from [RFC7950]:
- action
- augment
- container
- data model
- data node
- feature
- leaf
- list
- mandatory node
- module
- presence container
- schema tree
- RPC (Remote Procedure Call) operation
2.1. Glossary of New Terms 🦋
core routing data model: YANG data model made up of the "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 holding a list of routes, plus other info. See Section 5.2 for details 💅
system-controlled entry: An entry in a list in the operational state ("config false") that the system creates on its own, regardless of what's been explicitly configured. See Section 4.1 for details ✨
user-controlled entry: An entry in a list in the operational state ("config false") that gets created and deleted as a direct result of certain configuration changes. See Section 4.1 for details 💖
2.2. Tree Diagrams 🌸
Tree diagrams in this doc follow the notation in [RFC8340] 🎀
2.3. Prefixes in Data Node Names 🧚
Names of data nodes, actions, and other data model objects often get used without a prefix, as long as it's clear from context which YANG module they're defined in 🫶 Otherwise they get prefixed with the standard prefix for their YANG module, as shown in Table 1 💅
+--------+---------------------------+-----------+
| Prefix | YANG module | Reference |
+--------+---------------------------+-----------+
| if | ietf-interfaces | [RFC8343] |
| ip | ietf-ip | [RFC8344] |
| 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 Modules3. Objectives 🌈
The first design of the core routing data model was driven by these goals 🎯✨
- The data model should be suitable for the common address families (especially IPv4 and IPv6), and for unicast and multicast routing, plus Multiprotocol Label Switching (MPLS) 💖
- A simple IP routing system, like one that only does static routing, should be configurable in a simple way, ideally with no need to develop extra YANG modules 🦋
- On the flip side, the core framework must allow for complicated setups with multiple RIBs and multiple control-plane protocols, plus controlled redistribution of routing info 🔥
- Because device vendors will want to map models built on this generic framework onto their proprietary models and config interfaces, the framework should be flexible enough to make that mapping easy and to handle models with different logic 🌸
Part 1 of 13 is done, bestie 🫶 Keep an eye out for part 2 💅✨
4. The Design of the Core Routing Data Model ✨
okay so the core routing data model is made of three YANG modules and one submodule 🎀 The first one, "ietf-routing", holds the generic parts of a routing system. The other two, "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing", augment "ietf-routing" with extra data nodes for IPv4 and IPv6 unicast routing, respectively. The "ietf-ipv6-unicast-routing" module also has a submodule called "ietf-ipv6-router-advertisements". It augments the "ietf-interfaces" [RFC8343] and "ietf-ip" [RFC8344] modules with configuration variables for IPv6 Router Advertisements, as required by [RFC4861]. slay 💅
Figure 1 gives you abridged views of the hierarchies. For the complete data trees, go check Appendix A 🌸
+--rw routing
+--rw router-id? yang:dotted-quad
+--ro interfaces
| +--ro interface* if:interface-ref
+--rw control-plane-protocols
| +--rw control-plane-protocol* [type name]
| +--rw type identityref
| +--rw name string
| +--rw description? string
| +--rw static-routes
| +--rw v4ur:ipv4
| | ...
| +--rw v6ur:ipv6
| ...
+--rw ribs
+--rw rib* [name]
+--rw name string
+--rw address-family? identityref
+--ro default-rib? boolean {multiple-ribs}?
+--ro routes
| +--ro route*
| ...
+---x active-route
| +---w input
| | +---w v4ur:destination-address? inet:ipv4-address
| | +---w v6ur:destination-address? inet:ipv6-address
| +--ro output
| ...
+--rw description? stringFigure 1: Data Hierarchy
As you can see in Figure 1, the core routing data model brings in a few generic components of a routing framework: routes, RIBs (which are lists of routes), and control-plane protocols. Section 5 breaks these components down in more detail 💜
4.1. System-Controlled and User-Controlled List Entries 🦋
The core routing data model defines several lists in the schema tree, like "rib", that have to be populated with at least one entry on any properly functioning device. Clients can add more entries on top of that 🫶
In a list like this, the server creates the required item as a "system-controlled entry" in the operational state. Put simply, that means it lives in the read-only lists under the "routing" container 👀
Appendix D has an example: the "/routing/ribs/rib" list has two system-controlled entries, "ipv4-master" and "ipv6-master" 🍓
Extra entries called "user-controlled entries" can be created in the configuration by a client, for example via the Network Configuration Protocol (NETCONF). If the server accepts a configured user-controlled entry, that entry also shows up in the operational state version of the list ✨
Corresponding entries in both versions of the list (the intended configuration and the operational state) [RFC8342] have the same value of the list key. Bestie, that's the whole matching trick 🔥
A client can also give supplemental configuration to system-controlled entries. To do that, the client creates a new entry in the configuration with the contents it wants. To bind this entry to the matching entry in the operational state, the key of the configuration entry has to be set to the same value as the key of the operational state entry 🎀
Deleting a user-controlled entry from the intended configuration removes the corresponding entry from the operational state list. It's giving clean. But if a client deletes a system-controlled entry from the intended configuration, only the extra configuration in that entry gets removed. The corresponding operational state entry is not removed 🙈
5. Basic Building Blocks 🧩
This section walks through the essential components of the core routing data model 💖
5.1. Routes 🛣️
Routes are the basic elements of information in a routing system. The core routing data model defines only the following minimal set of route attributes:
- "destination-prefix": an address prefix that specifies the set of destination addresses the route may be used for. This attribute is mandatory.
- "route-preference": an integer value (also known as "administrative distance") that is used to select a preferred route among routes with the same destination prefix. A lower value means a route that is more preferred 👑
- "next-hop": determines the outgoing interface and/or next-hop address(es), or a special operation to be performed on a packet.
Routes are mainly system state, and they show up as entries in RIBs (Section 5.2). They can also be found in configuration data, though. For example, you can manually configure static routes. In that case, the configurable route attributes are generally a subset of the attributes defined for RIB routes 🌈
5.2. Routing Information Base (RIB) 📚
Every implementation of the core routing data model manages one or more RIBs. A RIB is a list of routes plus 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 represented as entries in the list "/routing/ribs/rib" in the operational state. The contents of RIBs are controlled and manipulated by control-plane protocol operations, which can 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 "default RIB", which is where control-plane protocols place their routes by default. This one is a must, no cap 🫶
Simple router implementations that do not advertise the "multiple-ribs" feature will typically create one system-controlled RIB per supported address family and mark it as the default RIB 🍓
More-complex router implementations that advertise the "multiple-ribs" feature support multiple RIBs per address family. Those can be used for policy routing and other purposes 🔥
The following action (see Section 7.15 of [RFC7950]) is defined for the "rib" list:
- active-route -- returns the active RIB route for the destination address specified as the action's input parameter.
5.3. Control-Plane Protocol 🎀
The core routing data model gives you an open-ended framework for defining multiple control-plane protocol instances, for example 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 pseudo-protocols, which means they are confined to the local device and don't 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's 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" lets you specify routes manually. It MAY be configured in zero or multiple instances, although a typical configuration will have exactly one instance 🍓
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. Those new modules will have to define the protocol-specific data nodes, and they will have to integrate into the core routing framework in the following way:
- 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".
- 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 node
/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route
and possibly other places in the schema tree.
- Data nodes for the new protocol can be defined by augmenting the "control-plane-protocol" data node under "/routing".
By using a "when" statement, the augmented data nodes 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), which you can see in Appendix C 💖
5.4. Parameters of IPv6 Router Advertisements 📡
The YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is a submodule of the "ietf-ipv6-unicast-routing" module, augments the schema tree of IPv6 interfaces with definitions of the following variables, as required by Section 6.2.1 of [RFC4861]:
- send-advertisements
- max-rtr-adv-interval
- min-rtr-adv-interval
- managed-flag
- other-config-flag
- link-mtu
- reachable-time
- retrans-timer
- cur-hop-limit
- default-lifetime
- 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:
- The "IsRouter" flag, which is also required by [RFC4861], is implemented in the "ietf-ip" module [RFC8344] (leaf "ip:forwarding") 🧠
- The Neighbor Discovery specification [RFC4861] lets implementations decide whether the "valid-lifetime" and "preferred-lifetime" parameters stay the same in consecutive advertisements or decrement in real time. The decrementing option seems problematic, though, because the values might be reset to the (higher) configured values after a configuration is reloaded. Also, no implementation is known to use the decrementing behavior 😭 So the "ietf-ipv6-router-advertisements" submodule goes with the former behavior, with constant values 💅
6. Interactions with Other YANG Modules 🎀
The semantics of the core routing data model also depend 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 [RFC8343]:
/if:interfaces/if:interface/if:enabledIf this switch is set to "false" for a network-layer interface, then all routing and forwarding functions MUST be disabled on this interface. No exceptions, bestie 🙅♀️💀
6.2. Module "ietf-ip" 🌐
okay so the "ietf-ip" YANG module [RFC8344] gives us four boolean switches, and they are sooo important for keeping your interfaces in line 💅
/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. Like, all of them. 🙅♀️
/if:interfaces/if:interface/ip:ipv4/ip:forwarding
If this switch is set to "false" for a network-layer interface, then forwarding of IPv4 datagrams through this interface MUST be disabled. BUT the interface MAY still join in on other IPv4 routing functions, like routing protocols. so it's not totally cut off, just not forwarding 🦋
/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. same energy as the IPv4 one, just for IPv6 💜
/if:interfaces/if:interface/ip:ipv6/ip:forwarding
If this switch is set to "false" for a network-layer interface, then forwarding of IPv6 datagrams through this interface MUST be disabled. However, the interface MAY participate in other IPv6 routing functions, such as routing protocols. 🌸
Now the extra bit, and it's a good one! The "ietf-ip" module also lets you configure IPv4 and IPv6 addresses and network prefixes or masks on network-layer interfaces. When you configure these on an enabled interface, it MUST result in an immediate creation of the corresponding direct route ✨ The destination prefix of that route is set based on the configured IP address and network prefix/mask, and the interface gets set as the outgoing interface for that route. It's literally automatic, so iconic 🎀
7. Routing Management YANG Module 👑
Here's the big one: the routing management YANG module! 🧚 Here it is, copied exactly as written, so every single detail is still there.
<CODE BEGINS> file "ietf-routing@2018-03-13.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";
description
"An 'ietf-interfaces' module version that is compatible with
the Network Management Datastore Architecture (NMDA)
is required.";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:rtgwg@ietf.org>
Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>
Acee Lindem
<mailto:acee@cisco.com>
Yingzhen Qu
<mailto:yingzhen.qu@huawei.com>";
description
"This YANG module defines essential components for the management
of a routing subsystem. The model fully conforms to the Network
Management Datastore Architecture (NMDA).
Copyright (c) 2018 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
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8349; see
the RFC itself for full legal notices.";
revision 2018-03-13 {
description
"Network Management Datastore Architecture (NMDA) revision.";
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
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.
Servers that do not advertise this feature SHOULD provide
exactly one system-controlled RIB per supported address family
and also make it the default RIB. This RIB then appears as an
entry in the list '/routing/ribs/rib'.";
}
feature router-id {
description
"This feature indicates that the server supports 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 an IPv4 address family.";
}
identity ipv6 {
base address-family;
description
"This identity represents an 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
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 a 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.";
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 {
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 in 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.";
}
}
}
}
}
}
grouping next-hop-state-content {
description
"Generic state parameters of next hops.";
choice next-hop-options {
mandatory true;
description
"Options for next hops.
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-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 in 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-ref;
description
"Name of the outgoing interface.";
}
}
}
}
}
}We're still inside the YANG module, bestie, and this is where the routing tree really takes shape 🌸✨ The route metadata grouping is up first, then the live routing container, then the obsolete routing-state copy that got replaced by the datastore architecture 🦋
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
"The 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
"Timestamp 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.";
}
}
/* Data nodes */
container routing {
description
"Configuration parameters for the routing subsystem.";
uses router-id {
if-feature "router-id";
description
"Support for the global router ID. Routing protocols
that use a router ID can use this parameter or override it
with another value.";
}
container interfaces {
config false;
description
"Network-layer interfaces used for routing.";
leaf-list interface {
type if:interface-ref;
description
"Each entry is a reference to the name of a configured
network-layer interface.";
}
}
container control-plane-protocols {
description
"Support for control-plane protocol instances.";
list control-plane-protocol {
key "type name";
description
"Each entry contains a control-plane protocol instance.";
leaf type {
type identityref {
base control-plane-protocol;
}
description
"Type of the control-plane protocol -- an identity
derived 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
"Support for the 'static' pseudo-protocol.
Address-family-specific modules augment this node with
their lists of routes.";
}
}
}
container ribs {
description
"Support for RIBs.";
list rib {
key "name";
description
"Each entry contains a configuration for a RIB identified
by the 'name' key.
Entries having the same key as a system-controlled entry
in the list '/routing/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
in the operational state.
For user-controlled entries, an arbitrary name can be
used.";
}
uses address-family {
description
"The address family of the system-controlled RIB.";
}
leaf default-rib {
if-feature "multiple-ribs";
type boolean;
default "true";
config false;
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 {
config false;
description
"Current contents of the RIB.";
list route {
description
"A RIB route entry. This data node MUST be augmented
with information specific to 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 indicates a route that is
more preferred.";
}
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 {
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;
}
}
}
leaf description {
type string;
description
"Textual description of the RIB.";
}
}
}
}
/*
* The subsequent data nodes are obviated and obsoleted
* by the Network Management Datastore Architecture
* as described in RFC 8342.
*/
container routing-state {
config false;
status obsolete;
description
"State data of the routing subsystem.";
uses router-id {
status obsolete;
description
"Global router ID.
It may be either configured or assigned algorithmically by
the implementation.";
}
container interfaces {
status obsolete;
description
"Network-layer interfaces used for routing.";
leaf-list interface {
type if:interface-state-ref;
status obsolete;
description
"Each entry is a reference to the name of a configured
network-layer interface.";
}
}
container control-plane-protocols {
status obsolete;
description
"Container for the list of routing protocol instances.";
list control-plane-protocol {
key "type name";
status obsolete;
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;
}
status obsolete;
description
"Type of the control-plane protocol.";
}
leaf name {
type string;
status obsolete;
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 {
status obsolete;
description
"Container for RIBs.";
list rib {
key "name";
min-elements 1;
status obsolete;
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 {
type string;
status obsolete;
description
"The name of the RIB.";
}
uses address-family {
status obsolete;
description
"The address family of the RIB.";
}
leaf default-rib {
if-feature "multiple-ribs";
type boolean;
default "true";
status obsolete;
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 {
status obsolete;
description
"Current contents of the RIB.";
list route {
status obsolete;
description
"A RIB route entry. This data node MUST be augmented
with information specific to routes of each address
family.";
leaf route-preference {
type route-preference;
status obsolete;
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 indicates a route that is
more preferred.";
}
container next-hop {
status obsolete;
description
"Route's next-hop attribute.";
uses next-hop-state-content {
status obsolete;
description
"Route's next-hop attribute operational state.";
}
}
uses route-metadata {
status obsolete;
description
"Route metadata.";
}
}
}
action active-route {
status obsolete;
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 {
container route {
status obsolete;
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 {
status obsolete;
description
"Route's next-hop attribute.";
uses next-hop-state-content {
status obsolete;
description
"Active route state data.";
}
}
uses route-metadata {
status obsolete;
description
"Active route metadata.";
}
}
}
}
}
}
}
}
<CODE ENDS>8. IPv4 Unicast Routing Management YANG Module ✨
okay bestie, this is the IPv4 unicast module 🦋 it's giving augment party, so get comfy 💅
<CODE BEGINS> file "ietf-ipv4-unicast-routing@2018-03-13.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";
description
"An 'ietf-routing' module version that is compatible with
the Network Management Datastore Architecture (NMDA)
is required.";
}
import ietf-inet-types {
prefix "inet";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:rtgwg@ietf.org>
Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>
Acee Lindem
<mailto:acee@cisco.com>
Yingzhen Qu
<mailto:yingzhen.qu@huawei.com>";
description
"This YANG module augments the 'ietf-routing' module with basic
parameters for IPv4 unicast routing. The model fully conforms
to the Network Management Datastore Architecture (NMDA).
Copyright (c) 2018 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
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8349; see
the RFC itself for full legal notices.";
revision 2018-03-13 {
description
"Network Management Datastore Architecture (NMDA) revision.";
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
revision 2016-11-04 {
description
"Initial revision.";
reference
"RFC 8022: A YANG Data Model for Routing Management";
}
/* Identities */
identity ipv4-unicast {
base rt:ipv4;
description
"This identity represents the IPv4 unicast address family.";
}
augment "/rt:routing/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/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
"Augments the '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/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.";
}
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/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/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/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, "
+ "'v4ur:ipv4-unicast')" {
description
"This augment is valid only for IPv4 unicast.";
}
description
"Augments the '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/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
"Augments the '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.";
}
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/rt:static-routes" {
description
"This augment defines the 'static' pseudo-protocol
with data specific to IPv4 unicast.";
container ipv4 {
description
"Support for 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:ipv4-prefix;
mandatory true;
description
"IPv4 destination prefix.";
}
leaf description {
type string;
description
"Textual description of the route.";
}
container next-hop {
description
"Support for next-hop.";
uses rt:next-hop-content {
augment "next-hop-options/simple-next-hop" {
description
"Augments the '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
"Augments the 'next-hop-list' case in IPv4 static
routes.";
leaf next-hop-address {
type inet:ipv4-address;
description
"IPv4 address of the next hop.";
}
}
}
}
}
}
}
/*
* The subsequent data nodes are obviated and obsoleted
* by the Network Management Datastore Architecture
* as described in RFC 8342.
*/
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.";
}
status obsolete;
description
"This leaf augments an IPv4 unicast route.";
leaf destination-prefix {
type inet:ipv4-prefix;
status obsolete;
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.";
}
status obsolete;
description
"Augments the 'simple-next-hop' case in IPv4 unicast routes.";
leaf next-hop-address {
type inet:ipv4-address;
status obsolete;
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.";
}
status obsolete;
description
"This leaf augments the 'next-hop-list' case of IPv4 unicast
routes.";
leaf address {
type inet:ipv4-address;
status obsolete;
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.";
}
status obsolete;
description
"This augment adds the input parameter of the 'active-route'
action."; leaf destination-address {
type inet:ipv4-address;
status obsolete;
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.";
}
status obsolete;
description
"This augment adds the destination prefix to the reply of the
'active-route' action.";
leaf destination-prefix {
type inet:ipv4-prefix;
status obsolete;
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" {
when "derived-from-or-self(../../../rt:address-family,
'v4ur:ipv4-unicast')" {
description
"This augment is valid only for IPv4 unicast.";
}
status obsolete;
description
"Augments the 'simple-next-hop' case in the reply to the
'active-route' action.";
leaf next-hop-address {
type inet:ipv4-address;
status obsolete;
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.";
}
status obsolete;
description
"Augments the 'next-hop-list' case in the reply to the
'active-route' action.";
leaf next-hop-address {
type inet:ipv4-address;
status obsolete;
description
"IPv4 address of the next hop.";
}
}
}
<CODE ENDS>9. IPv6 Unicast Routing Management YANG Module ✨
okay the IPv6 module is giving sequel energy, and it's a whole vibe 🧚💖
<CODE BEGINS> file "ietf-ipv6-unicast-routing@2018-03-13.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";
description
"An 'ietf-routing' module version that is compatible with
the Network Management Datastore Architecture (NMDA)
is required.";
}
import ietf-inet-types {
prefix "inet";
description
"An 'ietf-interfaces' module version that is compatible with
the Network Management Datastore Architecture (NMDA)
is required.";
}
include ietf-ipv6-router-advertisements {
revision-date 2018-03-13;
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:rtgwg@ietf.org>
Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>
Acee Lindem
<mailto:acee@cisco.com>
Yingzhen Qu
<mailto:yingzhen.qu@huawei.com>";
description
"This YANG module augments the 'ietf-routing' module with basic
parameters for IPv6 unicast routing. The model fully conforms
to the Network Management Datastore Architecture (NMDA).
Copyright (c) 2018 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
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8349; see
the RFC itself for full legal notices.";
revision 2018-03-13 {
description
"Network Management Datastore Architecture (NMDA) revision.";
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
/* Identities */
revision 2016-11-04 {
description
"Initial revision.";
reference
"RFC 8022: A YANG Data Model for Routing Management";
}
identity ipv6-unicast {
base rt:ipv6;
description
"This identity represents the IPv6 unicast address family.";
}
augment "/rt:routing/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.";
}
}
augment "/rt:routing/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
"Augments the '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/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/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;
description
"IPv6 destination address.";
}
}
augment "/rt:routing/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/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
"Augments the '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/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.";
}
description
"Augments the '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.";
}
}
/* Data node augmentations */
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/rt:static-routes" {
description
"This augment defines the 'static' pseudo-protocol
with data specific to IPv6 unicast.";
container ipv6 {
description
"Support for 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
"Next hop for the route.";
uses rt:next-hop-content {
augment "next-hop-options/simple-next-hop" {
description
"Augments the 'simple-next-hop' case in IPv6 static
routes.";
leaf next-hop-address {
type inet:ipv6-address;
description
"IPv6 address of the next hop.";
}
}
augment "next-hop-options/next-hop-list/next-hop-list/"
+ "next-hop" {
description
"Augments the 'next-hop-list' case in IPv6 static
routes.";
leaf next-hop-address {
type inet:ipv6-address;
description
"IPv6 address of the next hop.";
}
}
}
}
}
}
}
/*
* The subsequent data nodes are obviated and obsoleted
* by the Network Management Datastore Architecture
* as described in RFC 8342.
*/
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.";} status obsolete; description "This leaf augments an IPv6 unicast route."; leaf destination-prefix { type inet:ipv6-prefix; status obsolete; description "IPv6 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, 'v6ur:ipv6-unicast')" { description "This augment is valid only for IPv6 unicast."; } status obsolete; description "Augments the 'simple-next-hop' case in IPv6 unicast routes."; leaf next-hop-address { type inet:ipv6-address; status obsolete; 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."; } status obsolete; description "This leaf augments the 'next-hop-list' case of IPv6 unicast routes."; leaf address { type inet:ipv6-address; status obsolete; 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."; } status obsolete; description "This augment adds the input parameter of the 'active-route' action."; leaf destination-address { type inet:ipv6-address; status obsolete; 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."; } status obsolete; description "This augment adds the destination prefix to the reply of the 'active-route' action."; leaf destination-prefix { type inet:ipv6-prefix; status obsolete; 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."; } status obsolete; description "Augments the 'simple-next-hop' case in the reply to the 'active-route' action."; leaf next-hop-address {
type inet:ipv6-address; status obsolete; 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."; } status obsolete; description "Augments the 'next-hop-list' case in the reply to the 'active-route' action."; leaf next-hop-address { type inet:ipv6-address; status obsolete; description "IPv6 address of the next hop."; } } }
<CODE ENDS>
## 9.1. IPv6 Router Advertisements Submodule ✨
<pink>okay bestie, this submodule is where the IPv6 Router Advertisement knobs get bolted onto the `ietf-ip` stuff 💖</pink> <lavender>it's giving organized, no cap 🫶</lavender>
<CODE BEGINS> file "ietf-ipv6-router-advertisements@2018-03-13.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"; description "An 'ietf-interfaces' module version that is compatible with
the Network Management Datastore Architecture (NMDA) is required."; }
import ietf-ip { prefix "ip"; description "An 'ietf-ip' module version that is compatible with the Network Management Datastore Architecture (NMDA) is required."; }
organization "IETF NETMOD (Network Modeling) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/netmod/> WG List: <mailto:rtgwg@ietf.org>
Editor: Ladislav Lhotka <mailto:lhotka@nic.cz> Acee Lindem <mailto:acee@cisco.com> Yingzhen Qu <mailto:yingzhen.qu@huawei.com>";
description "This YANG module augments the 'ietf-ip' module with parameters for IPv6 Router Advertisements. The model fully conforms to the Network Management Datastore Architecture (NMDA).
Copyright (c) 2018 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 (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8349; see the RFC itself for full legal notices.";
reference "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)";
revision 2018-03-13 {
description "Network Management Datastore Architecture (NMDA) revision."; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; }
revision 2016-11-04 { description "Initial revision."; reference "RFC 8022: A YANG Data Model for Routing Management"; }
augment "/if:interfaces/if:interface/ip:ipv6" { description "Augments interface configuration with parameters of IPv6 Router Advertisements."; container ipv6-router-advertisements { description "Support for 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..65535"; } 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'."; } 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 { 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 IANA-specified value for the default IPv4 Time to Live (TTL) parameter that was in effect at the time of implementation."; reference "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an On-line Database RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
- AdvCurHopLimit
IANA: IP Parameters (https://www.iana.org/assignments/ip-parameters)"; } leaf default-lifetime { type uint16 { range "0..65535"; } units "seconds"; description "The value to be placed in the Router Lifetime field of 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 "Support for 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 "Support for an advertised prefix entry."; leaf prefix-spec { type inet:ipv6-prefix; description "IPv6 address prefix."; } choice control-adv-prefixes { default "advertise"; description "Either (1) the prefix is explicitly removed from the set of advertised prefixes or (2) the parameters with which the prefix is advertised are specified (default case)."; leaf no-advertise { type empty; description "The prefix will not be advertised.
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; 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"; } } } } } } }
/*
- The subsequent data nodes are obviated and obsoleted
- by the Network Management Datastore Architecture
- as described in RFC 8342. */ augment "/if:interfaces-state/if:interface/ip:ipv6" { status obsolete; description "Augments interface state data with parameters of IPv6 Router Advertisements."; container ipv6-router-advertisements { status obsolete; description "Parameters of IPv6 Router Advertisements."; leaf send-advertisements { type boolean; status obsolete; 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"; status obsolete; 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"; status obsolete; description "The minimum time allowed between sending unsolicited multicast Router Advertisements from the interface."; } leaf managed-flag { type boolean; status obsolete; description "The value that is placed in the 'Managed address configuration' flag field in the Router Advertisement."; } leaf other-config-flag { type boolean; status obsolete; description "The value that is placed in the 'Other configuration' flag field in the Router Advertisement."; } leaf link-mtu { type uint32; status obsolete; 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"; status obsolete; 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"; status obsolete; 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; status obsolete; 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"; status obsolete; 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 { status obsolete; description "A list of prefixes that are placed in Prefix Information options in Router Advertisement messages sent from the interface.
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"; status obsolete; description "Advertised prefix entry and its parameters."; leaf prefix-spec { type inet:ipv6-prefix; status obsolete; description "IPv6 address prefix."; } leaf valid-lifetime { type uint32; units "seconds"; status obsolete; 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; status obsolete; 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"; status obsolete; 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; status obsolete; description "The value that is placed in the Autonomous Flag field in the Prefix Information option.";
} } } } } }
<CODE ENDS>
<lavender>okay so the last bit is the obsolete augment 🥺🫶 it's giving "we're retiring these nodes" because the Network Management Datastore Architecture from RFC 8342 took over their job</lavender> ✨
# 10. IANA Considerations ✨
okay so IANA already did the namespace stuff, bestie 🎀 [RFC8022] registered three namespace URIs in the "IETF XML Registry" [RFC3688], and IANA has since updated the references so they point to this document 💅
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.
Same energy for the YANG modules 🦋 [RFC8022] put three modules in the "YANG Module Names" registry [RFC6020]. IANA updated two things for each one: the module entries themselves, and the references, which now point to RFC 8349 🌸
Name: ietf-routing Namespace: urn:ietf:params:xml:ns:yang:ietf-routing Prefix: rt Reference: RFC 8349
Name: ietf-ipv4-unicast-routing Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing Prefix: v4ur Reference: RFC 8349
Name: ietf-ipv6-unicast-routing Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing Prefix: v6ur Reference: RFC 8349
This document also adds one new YANG submodule to the "YANG Module Names" registry [RFC6020] ✨
Name: ietf-ipv6-router-advertisements Module: ietf-ipv6-unicast-routing Reference: RFC 8349
---
# 11. Security Considerations 🔥
okay this section is SERIOUS, so read it properly 🙈 The YANG modules in this document define a schema for data that's meant to be reached through network management protocols like NETCONF [RFC6241] or RESTCONF [RFC8040]. The bottom NETCONF layer is the secure transport layer, and the secure transport every NETCONF implementation has to support is Secure Shell (SSH) [RFC6242]. The bottom RESTCONF layer is HTTPS, and the secure transport every RESTCONF implementation has to support is TLS [RFC5246] 🔒
The NETCONF access control model [RFC8341] lets you lock particular NETCONF or RESTCONF users down to a preconfigured subset of protocol operations and content. It's giving bodyguard 💖
Now the writable stuff. A bunch of data nodes here are writable, creatable, and deletable (that's `config true`, which is the default) 💅 These nodes can be sensitive or vulnerable in some network environments. If you do write operations (like edit-config) to them without proper protection, that can hurt network operations. Here are the subtrees and nodes and why they're sensitive:
- `/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.
Some of the readable data nodes can also be sensitive or vulnerable, so controlling read access is important 👀 That means get, get-config, and notifications. Here's the breakdown:
- `/routing/control-plane-protocols/control-plane-protocol:` This list specifies the control-plane protocols configured on a device. Check the control-plane models for a list of sensitive information.
- `/routing/ribs/rib:` This list specifies the RIBs and their contents for the device. Access to this information may disclose the network topology and/or other information.
Some RPC operations in this YANG module can be sensitive or vulnerable too, so controlling access to them matters 🫶 Here's the one, and its sensitivity:
- `/routing/ribs/rib/active-route:` The output from this RPC operation returns the route being used for a specified destination. Access to this information may disclose the network topology or relationship (e.g., client/provider). On top of that, the routes a network device uses could be used to mount a follow-up attack on traffic going through that device 😭
---
# 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, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://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, <https://www.rfc-editor.org/info/rfc4861>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://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, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", RFC 8022, DOI 10.17487/RFC8022, November 2016, <https://www.rfc-editor.org/info/rfc8022>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.
## 12.2. Informative References 🧚
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014, <https://www.rfc-editor.org/info/rfc7224>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, <https://www.rfc-editor.org/info/rfc7895>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[YANG-Guidelines] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", Work in Progress, draft-ietf-netmod-rfc6087bis-20, March 2018.
---
# Appendix A. The Complete Schema Tree 🌈
okay the big finale 💜 This appendix shows the complete tree of the core routing data model. For an explanation of the symbols, check out [RFC8340] 🦋 The data type of every leaf node is shown near the right end of its line, so keep your eyes on the right side 👑
Okay so this is the whole ietf-routing tree, laid out in one go, and it's giving main character energy 💅✨
module: ietf-routing +--rw routing
| +--rw router-id? yang:dotted-quad | ||||
|---|---|---|---|---|
| +--ro interfaces | ||||
| +--ro interface* if:interface-ref | ||||
| +--rw control-plane-protocols | ||||
| +--rw control-plane-protocol* [type name] | ||||
| +--rw type identityref | ||||
| +--rw name string | ||||
| +--rw description? string | ||||
| +--rw static-routes | ||||
| +--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? | ||||
| if:interface-ref | ||||
| +--rw v4ur:next-hop-address? | ||||
| inet:ipv4-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] | ||||
| +--rw v4ur:index | ||||
| string | ||||
| +--rw v4ur:outgoing-interface? | ||||
| if:interface-ref | ||||
| +--rw v4ur:next-hop-address? | ||||
| inet:ipv4-address | ||||
| +--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? | ||||
| if:interface-ref | ||||
| +--rw v6ur:next-hop-address? | ||||
| inet:ipv6-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? | ||||
| if:interface-ref | ||||
| +--rw v6ur:next-hop-address? | ||||
| inet:ipv6-address | ||||
| +--rw ribs | ||||
| +--rw rib* [name] | ||||
| +--rw name string | ||||
| +--rw 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? | ||||
| if:interface-ref | ||||
| +--ro v4ur:next-hop-address? | ||||
| inet:ipv4-address | ||||
| +--ro v6ur:next-hop-address? | ||||
| inet:ipv6-address | ||||
| +--:(special-next-hop) | ||||
| +--ro special-next-hop? enumeration | ||||
| +--:(next-hop-list) | ||||
| +--ro next-hop-list | ||||
| +--ro next-hop* | ||||
| +--ro outgoing-interface? | ||||
| if:interface-ref | ||||
| +--ro v4ur:address? | ||||
| inet:ipv4-address | ||||
| +--ro v6ur:address? | ||||
| inet:ipv6-address | ||||
| +--ro source-protocol identityref | ||||
| +--ro active? empty | ||||
| +--ro last-updated? yang:date-and-time | ||||
| +--ro v4ur:destination-prefix? inet:ipv4-prefix | ||||
| +--ro v6ur:destination-prefix? inet:ipv6-prefix | ||||
| +---x active-route | ||||
| +---w input | ||||
| +---w v4ur:destination-address? inet:ipv4-address | ||||
| +---w v6ur:destination-address? inet:ipv6-address | ||||
| +--ro output | ||||
| +--ro route | ||||
| +--ro next-hop | ||||
| +--ro (next-hop-options) | ||||
| +--:(simple-next-hop) | ||||
| +--ro outgoing-interface? | ||||
| if:interface-ref | ||||
| +--ro v4ur:next-hop-address? | ||||
| inet:ipv4-address | ||||
| +--ro v6ur:next-hop-address? | ||||
| inet:ipv6-address | ||||
| +--:(special-next-hop) | ||||
| +--ro special-next-hop? | ||||
| enumeration | ||||
| +--:(next-hop-list) | ||||
| +--ro next-hop-list | ||||
| +--ro next-hop* | ||||
| +--ro outgoing-interface? | ||||
| if:interface-ref | ||||
| +--ro v4ur:next-hop-address? | ||||
| inet:ipv4-address | ||||
| +--ro v6ur:next-hop-address? | ||||
| inet:ipv6-address | ||||
| +--ro source-protocol identityref | ||||
| +--ro active? empty | ||||
| +--ro last-updated? | ||||
| yang:date-and-time | ||||
| +--ro v4ur:destination-prefix? | ||||
| inet:ipv4-prefix | ||||
| +--ro v6ur:destination-prefix? | ||||
| inet:ipv6-prefix | ||||
| +--rw description? string |
o--ro routing-state o--ro router-id? yang:dotted-quad o--ro interfaces
| o--ro interface* if:interface-state-ref |
o--ro control-plane-protocols
| o--ro control-plane-protocol* [type name] |
|---|
| o--ro type identityref |
| o--ro name string |
o--ro ribs o--ro rib* [name] o--ro name string o--ro address-family identityref o--ro default-rib? boolean {multiple-ribs}? o--ro routes
| o--ro route* | |||
|---|---|---|---|
| o--ro route-preference? route-preference | |||
| o--ro next-hop | |||
| o--ro (next-hop-options) | |||
| o--:(simple-next-hop) | |||
| o--ro outgoing-interface? | |||
| if:interface-ref | |||
| o--ro v4ur:next-hop-address? | |||
| inet:ipv4-address | |||
| o--ro v6ur:next-hop-address? | |||
| inet:ipv6-address | |||
| o--:(special-next-hop) | |||
| o--ro special-next-hop? enumeration | |||
| o--:(next-hop-list) | |||
| o--ro next-hop-list | |||
| o--ro next-hop* | |||
| o--ro outgoing-interface? | |||
| if:interface-ref | |||
| o--ro v4ur:address? | |||
| inet:ipv4-address | |||
| o--ro v6ur:address? | |||
| inet:ipv6-address | |||
| o--ro source-protocol identityref | |||
| o--ro active? empty | |||
| o--ro last-updated? yang:date-and-time | |||
| o--ro v4ur:destination-prefix? inet:ipv4-prefix | |||
| o--ro v6ur:destination-prefix? inet:ipv6-prefix |
o---x active-route o---w input
| o---w v4ur:destination-address? inet:ipv4-address |
|---|
| o---w v6ur:destination-address? inet:ipv6-address |
o--ro output
o--ro route o--ro next-hop
| o--ro (next-hop-options) | ||
|---|---|---|
| o--:(simple-next-hop) | ||
| o--ro outgoing-interface? | ||
| if:interface-ref | ||
| o--ro v4ur:next-hop-address? | ||
| inet:ipv4-address | ||
| o--ro v6ur:next-hop-address? | ||
| inet:ipv6-address | ||
| o--:(special-next-hop) | ||
| o--ro special-next-hop? | ||
| enumeration | ||
| o--:(next-hop-list) | ||
| o--ro next-hop-list | ||
| o--ro next-hop* | ||
| o--ro outgoing-interface? | ||
| if:interface-ref | ||
| o--ro v4ur:next-hop-address? | ||
| inet:ipv4-address | ||
| o--ro v6ur:next-hop-address? | ||
| inet:ipv6-address |
o--ro source-protocol identityref o--ro active? empty o--ro last-updated?
| yang:date-and-time |
o--ro v4ur:destination-prefix?
| inet:ipv4-prefix |
o--ro v6ur:destination-prefix? inet:ipv6-prefix module: ietf-ipv6-unicast-routing augment /if:interfaces/if:interface/ip:ipv6: +--rw ipv6-router-advertisements +--rw send-advertisements? boolean +--rw max-rtr-adv-interval? uint16 +--rw min-rtr-adv-interval? uint16 +--rw managed-flag? boolean +--rw other-config-flag? boolean +--rw link-mtu? uint32 +--rw reachable-time? uint32 +--rw retrans-timer? uint32 +--rw cur-hop-limit? uint8 +--rw default-lifetime? uint16 +--rw prefix-list +--rw prefix* [prefix-spec] +--rw prefix-spec inet:ipv6-prefix +--rw (control-adv-prefixes)? +--:(no-advertise)
| +--rw no-advertise? empty |
+--:(advertise) +--rw valid-lifetime? uint32 +--rw on-link-flag? boolean +--rw preferred-lifetime? uint32 +--rw autonomous-flag? boolean augment /if:interfaces-state/if:interface/ip:ipv6: o--ro ipv6-router-advertisements o--ro send-advertisements? boolean o--ro max-rtr-adv-interval? uint16 o--ro min-rtr-adv-interval? uint16 o--ro managed-flag? boolean o--ro other-config-flag? boolean o--ro link-mtu? uint32 o--ro reachable-time? uint32 o--ro retrans-timer? uint32 o--ro cur-hop-limit? uint8 o--ro default-lifetime? uint16 o--ro prefix-list o--ro prefix* [prefix-spec] o--ro prefix-spec inet:ipv6-prefix o--ro valid-lifetime? uint32 o--ro on-link-flag? boolean o--ro preferred-lifetime? uint32 o--ro autonomous-flag? boolean
# Appendix B. Minimum Implementation 🌸
Okay bestie, so this appendix is the "hey, I'm just a host or a tiny router, don't panic" section 💅. Some parts and options of the core routing model, like user-defined RIBs, are really meant for advanced routers 🖥️. So this appendix gives basic, non-normative guidelines for implementing a bare minimum of the available functions ✨. A setup like this can be used for hosts or very simple routers 🦋.
A minimum implementation does not support the "multiple-ribs" feature. That means there's a single system-controlled RIB for each supported address family, which is IPv4, IPv6, or both 💜. These RIBs are also the default RIBs, and no user-controlled RIBs are allowed 🙅.
On top of 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 🫶. No router vibes needed there, periodt 💀.
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 🦋
Okay so this appendix shows how the core routing data model can be extended to support a brand new control-plane protocol, and it's honestly iconic 🌈. The YANG module "example-rip" below is just an illustration, not a real data model for RIP (the Routing Information Protocol) 🧚. For the sake of brevity, this module does not obey all the guidelines in [YANG-Guidelines] 🙈. 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 { type uint16; default "0"; description "This leaf may be used to carry additional information, e.g., an autonomous system (AS) number."; } }
augment "/rt:routing/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/rt:ribs/rt:rib/rt:active-route/"
- "rt:output/rt:route" { description "RIP-specific route attributes in the output of an '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 { 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 ✨
Okay bestie, this part is my favourite because we get to look at a real instance data tree 🦋 It's encoded in JSON [RFC7951] and it shows what the operational state actually looks like. (Heads up: this example also uses "iana-if-type", which is defined in [RFC7224] 💜)
The data conforms to a data model defined by the following YANG library specification [RFC7895] 📚:
{ "ietf-yang-library:modules-state": { "module-set-id": "c2e1f54169aa7f36e1a6e8d0865d441d3600f9c4", "module": [ { "name": "ietf-routing", "revision": "2018-03-13", "feature": [ "multiple-ribs", "router-id" ], "namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", "conformance-type": "implement" }, { "name": "ietf-ipv4-unicast-routing", "revision": "2018-03-13", "namespace": "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing", "conformance-type": "implement" }, { "name": "ietf-ipv6-unicast-routing", "revision": "2018-03-13", "namespace": "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing", "conformance-type": "implement", "submodule": [ { "name": "ietf-ipv6-router-advertisements", "revision": "2018-03-13" } ] }, { "name": "ietf-interfaces", "revision": "2018-02-20", "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": "2014-05-08", "conformance-type": "implement" }, { "name": "ietf-ip", "revision": "2018-02-22", "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", "conformance-type": "implement" } ] } }
Now let's set the scene 🎀 We're assuming a simple network setup, shown in Figure 2. Router "A" uses static default routes with the "ISP" router as its next hop 🌸 IPv6 Router Advertisements are configured only on the "eth1" interface and are 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 2: Example of Network Configuration
And here's the instance data tree that could come out of that setup 👑
{ "ietf-interfaces:interfaces": { "interface": [ { "name": "eth0", "type": "iana-if-type:ethernetCsmacd", "description": "Uplink to ISP.", "phys-address": "00:0C:42:E5:B1:E9", "oper-status": "up", "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 } ], "autoconf": { "create-global-addresses": false }, "ietf-ipv6-unicast-routing:ipv6-router-advertisements": { "send-advertisements": false } } }, { "name": "eth1", "type": "iana-if-type:ethernetCsmacd", "description": "Interface to the internal network.", "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, "address": [ { "ip": "2001:0db8:0:2::1", "prefix-length": 64 } ], "autoconf": { "create-global-addresses": false }, "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" } } ] }
} } ] }, "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", "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": { "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" } ] } } ] } } }
# Appendix E. NETCONF Get Data Reply Example ✨
okay so this is the grand finale 💅 It's a full example of what a NETCONF `<get-data>` reply looks like when you ask for `<operational>` data from a device running the example data models we've been talking about. It's an XML [W3C.REC-xml-20081126] reply, so the whole thing is one big <lavender>XML</lavender> moment 🎀
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <data> <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing" xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<router-id or:origin="or:intended">192.0.2.1</router-id> <control-plane-protocols or:origin="or:intended"> <control-plane-protocol> <type>ietf-routing:static</type> <name>static-routing-protocol</name> <static-routes> <ietf-ipv4-unicast-routing:ipv4> <route> <destination-prefix>0.0.0.0/0</destination-prefix> <next-hop> <next-hop-address>192.0.2.2</next-hop-address> </next-hop> </route> </ietf-ipv4-unicast-routing:ipv4> <ietf-ipv6-unicast-routing:ipv6> <route> <destination-prefix>::/0</destination-prefix> <next-hop> <next-hop-address>2001:db8:0:1::2</next-hop-address> </next-hop> </route> </ietf-ipv6-unicast-routing:ipv6> </static-routes> </control-plane-protocol> </control-plane-protocols>
<ribs> <rib or:origin="or:intended"> <name>ipv4-master</name> <address-family> ietf-ipv4-unicast-routing:ipv4-unicast </address-family> <default-rib>true</default-rib> <routes>
<route> <ietf-ipv4-unicast-routing:destination-prefix> 192.0.2.1/24 </ietf-ipv4-unicast-routing:destination-prefix> <next-hop> <outgoing-interface>eth0</outgoing-interface> </next-hop> <route-preference>0</route-preference> <source-protocol>ietf-routing:direct</source-protocol> <last-updated>2015-10-24T17:11:27+02:00</last-updated> </route> <route> <ietf-ipv4-unicast-routing:destination-prefix> 198.51.100.0/24 </ietf-ipv4-unicast-routing:destination-prefix> <next-hop> <outgoing-interface>eth1</outgoing-interface> </next-hop> <route-preference>0</route-preference> <source-protocol>ietf-routing:direct</source-protocol> <last-updated>2015-10-24T17:11:27+02:00</last-updated> </route> <route> <ietf-ipv4-unicast-routing:destination-prefix>0.0.0.0/0 </ietf-ipv4-unicast-routing:destination-prefix> <next-hop> <ietf-ipv4-unicast-routing:next-hop-address>192.0.2.2 </ietf-ipv4-unicast-routing:next-hop-address> </next-hop> <route-preference>5</route-preference> <source-protocol>ietf-routing:static</source-protocol> <last-updated>2015-10-24T18:02:45+02:00</last-updated> </route> </routes> </rib> <rib or:origin="or:intended"> <name>ipv6-master</name> <address-family> ietf-ipv6-unicast-routing:ipv6-unicast </address-family> <default-rib>true</default-rib> <routes> <route> <ietf-ipv6-unicast-routing:destination-prefix> 2001:db8:0:1::/64 </ietf-ipv6-unicast-routing:destination-prefix> <next-hop> <outgoing-interface>eth0</outgoing-interface>
</next-hop> <route-preference>0</route-preference> <source-protocol>ietf-routing:direct</source-protocol> <last-updated>2015-10-24T17:11:27+02:00</last-updated> </route> <route> <ietf-ipv6-unicast-routing:destination-prefix> 2001:db8:0:2::/64 </ietf-ipv6-unicast-routing:destination-prefix> <next-hop> <outgoing-interface>eth1</outgoing-interface> </next-hop> <route-preference>0</route-preference> <source-protocol>ietf-routing:direct</source-protocol> <last-updated>2015-10-24T17:11:27+02:00</last-updated> </route> <route> <ietf-ipv6-unicast-routing:destination-prefix>::/0 </ietf-ipv6-unicast-routing:destination-prefix> <next-hop> <ietf-ipv6-unicast-routing:next-hop-address> 2001:db8:0:1::2 </ietf-ipv6-unicast-routing:next-hop-address> </next-hop> <route-preference>5</route-preference> <source-protocol>ietf-routing:static</source-protocol> <last-updated>2015-10-24T18:02:45+02:00</last-updated> </route> </routes> </rib> </ribs> </routing> </data> </rpc-reply>
---
# Acknowledgments 🫶
the authors wanna thank this whole squad for their helpful comments and suggestions 🌸 Nitin Bahadur, Martin Bjorklund, Dean Bogdanovic, Joe Clarke, Francis Dupont, Jeff Haas, Joel Halpern, Wes Hardaker, Jia He, Sriganesh Kini, Suresh Krishnan, David Lamparter, Xiang Li, Stephane Litkowski, Andrew McGregor, Jan Medved, Thomas Morin, Tom Petch, Bruno Rijsman, Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Vladimir Vassilev, Rob Wilton, Yi Yang, Derek Man-Kit Yeung, and Jeffrey Zhang 👑 literally the dream team, no notes 💖
---
# Authors' Addresses 💌
the authors, and where to find them 🦋
Ladislav Lhotka CZ.NIC
Email: lhotka@nic.cz
Acee Lindem Cisco Systems
Email: acee@cisco.com
Yingzhen Qu Huawei 2330 Central Expressway Santa Clara, CA 95050 United States of America
Email: yingzhen.qu@huawei.com
📦 where this page comes from
- ietf: rfc8349 2018-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms