RFC 8344
A YANG Data Model for IP Management
RFC 8344: A YANG Data Model for IP Management 💖
Okay bestie, so this is RFC 8344, and it's the IETF's official spec for a YANG data model that manages IP stuff on devices 🌸 It's from the Internet Engineering Task Force (IETF) and written by M. Bjorklund at Tail-f Systems. It's a Standards Track doc (so this is the real, implement-it-for-real kind 💅) dated March 2018. It obsoletes RFC 7277, so that one is retired 👋 The ISSN is 2070-1721 if you're keeping receipts 🎀
Abstract 🎀
So the big idea is that this doc defines a YANG data model for managing IP implementations. It covers both configuration and system state, which is the whole package 📦
The data model follows the Network Management Datastore Architecture from RFC 8342, aka NMDA, so it's giving architecture-approved energy ✨
This document obsoletes RFC 7277 🦋
Status of This Memo 🌈
This is an Internet Standards Track document 💜
It's a product of the IETF and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🫶
Want the current status, any errata, or a place to send feedback? Head to https://www.rfc-editor.org/info/rfc8344 🔥
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, which you can find at https://trustee.ietf.org/license-info. Those are the version in effect on the publication date, so please read them carefully because they spell out 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 with no warranty, as described in the Simplified BSD License 🧚
Table of Contents 🌸
1. Introduction ....................................................2
1.1. Summary of Changes from RFC 7277 ...........................2
1.2. Terminology ................................................3
1.3. Tree Diagrams ..............................................3
2. IP Data Model ...................................................4
3. Relationship to the IP-MIB ......................................5
4. IP Management YANG Module .......................................7
5. IANA Considerations ............................................27
6. Security Considerations ........................................27
7. References .....................................................29
7.1. Normative References ......................................29
7.2. Informative References ....................................31
Appendix A. Example: NETCONF <get-config> Reply ...................32
Appendix B. Example: NETCONF <get-data> Reply .....................33
Acknowledgments ...................................................34
Author's Address ..................................................341. Introduction ✨
Okay so this doc defines a YANG data model [RFC7950] for managing IP implementations 💅
The data model covers configuration of per-interface IPv4 and IPv6 parameters, plus mappings from IP addresses to link-layer addresses. It also tells you which IP addresses are operationally in use and which link-layer mappings exist 👑 The per-interface parameters get added through augmentation of the interface data model from [RFC8343] 🦋
This version of the IP data model supports the Network Management Datastore Architecture (NMDA) [RFC8342] 🫶
1.1. Summary of Changes from RFC 7277 🔥
Here's the tea ☕ The "ipv4" and "ipv6" subtrees with "config false" data nodes under "/interfaces-state/interface" are now deprecated 💀 All the "config false" data nodes now live in the "ipv4" and "ipv6" subtrees under "/interfaces/interface" instead 🌈
Servers that don't implement NMDA, or that want to support clients that don't implement NMDA, MAY implement the deprecated "ipv4" and "ipv6" subtrees under "/interfaces-state/interface" 🧚
1.2. Terminology 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀
These terms are defined in [RFC8342] and aren't redefined here:
- client
- server
- configuration
- system state
- intended configuration
- running configuration datastore
- operational state
- operational state datastore
These terms are defined in [RFC7950] and aren't redefined here:
- augment
- data model
- data node
The terminology for describing YANG data models lives in [RFC7950] 🌸
1.3. Tree Diagrams 🦋
Tree diagrams in this document follow the notation defined in [RFC8340] 💖
2. IP Data Model 🌈
This document defines the YANG module "ietf-ip". It augments the "interface" lists defined in the "ietf-interfaces" module [RFC8343] with IP-specific data nodes 🧚
The data model has this structure for IP data nodes per interface, excluding the deprecated data nodes 👑
module: ietf-ip
augment /if:interfaces/if:interface:
+--rw ipv4!
| +--rw enabled? boolean
| +--rw forwarding? boolean
| +--rw mtu? uint16
| +--rw address* [ip]
| | +--rw ip inet:ipv4-address-no-zone
| | +--rw (subnet)
| | | +--:(prefix-length)
| | | | +--rw prefix-length? uint8
| | | +--:(netmask)
| | | +--rw netmask? yang:dotted-quad
| | | {ipv4-non-contiguous-netmasks}?
| | +--ro origin? ip-address-origin
| +--rw neighbor* [ip]
| +--rw ip inet:ipv4-address-no-zone
| +--rw link-layer-address yang:phys-address
| +--ro origin? neighbor-origin
+--rw ipv6!
+--rw enabled? boolean
+--rw forwarding? boolean
+--rw mtu? uint32
+--rw address* [ip]
| +--rw ip inet:ipv6-address-no-zone
| +--rw prefix-length uint8
| +--ro origin? ip-address-origin
| +--ro status? enumeration
+--rw neighbor* [ip]
| +--rw ip inet:ipv6-address-no-zone
| +--rw link-layer-address yang:phys-address
| +--ro origin? neighbor-origin
| +--ro is-router? empty
| +--ro state? enumeration
+--rw dup-addr-detect-transmits? uint32
+--rw autoconf
+--rw create-global-addresses? boolean
+--rw create-temporary-addresses? boolean
| {ipv6-privacy-autoconf}?
+--rw temporary-valid-lifetime? uint32
| {ipv6-privacy-autoconf}?
+--rw temporary-preferred-lifetime? uint32
{ipv6-privacy-autoconf}?The data model defines two containers per interface, "ipv4" and "ipv6", which represent the IPv4 and IPv6 address families 💅 Each container has a leaf "enabled" that controls whether the address family is enabled on that interface, and a leaf "forwarding" that controls whether IP packet forwarding for that address family is enabled on the interface 🔥 Each container also has a list of addresses and a list of mappings from IP addresses to link-layer addresses ✨
3. Relationship to the IP-MIB 🧚
If the device implements the IP-MIB [RFC4293], each entry in the "ipv4/address" and "ipv6/address" lists maps to one ipAddressEntry. The ipAddressIfIndex refers to the interface of that "address" entry 🦋
The IP-MIB defines objects for controlling IPv6 Router Advertisement messages. The matching YANG data nodes are defined in [RFC8022] 🌈
The entries in "ipv4/neighbor" and "ipv6/neighbor" map to ipNetToPhysicalTable 💜
Here's the table of YANG data nodes and their matching IP-MIB objects 🎀
+----------------------------------+--------------------------------+
| YANG data node in | IP-MIB object |
| /if:interfaces/if:interface | |
+----------------------------------+--------------------------------+
| ipv4 | ipv4InterfaceEnableStatus |
| ipv4/enabled | ipv4InterfaceEnableStatus |
| ipv4/address | ipAddressEntry |
| ipv4/address/ip | ipAddressAddrType |
| | ipAddressAddr |
| ipv4/neighbor | ipNetToPhysicalEntry |
| ipv4/neighbor/ip | ipNetToPhysicalNetAddressType |
| | ipNetToPhysicalNetAddress |
| ipv4/neighbor/link-layer-address | ipNetToPhysicalPhysAddress |
| ipv4/neighbor/origin | ipNetToPhysicalType |
| ipv6 | ipv6InterfaceEnableStatus |
| ipv6/enabled | ipv6InterfaceEnableStatus |
| ipv6/forwarding | ipv6InterfaceForwarding |
| ipv6/address | ipAddressEntry |
| ipv6/address/ip | ipAddressAddrType |
| | ipAddressAddr |
| ipv4/address/origin | ipAddressOrigin |
| ipv6/address/status | ipAddressStatus |
| ipv6/neighbor | ipNetToPhysicalEntry |
| ipv6/neighbor/ip | ipNetToPhysicalNetAddressType |
| | ipNetToPhysicalNetAddress |
| ipv6/neighbor/link-layer-address | ipNetToPhysicalPhysAddress |
| ipv6/neighbor/origin | ipNetToPhysicalType |
| ipv6/neighbor/state | ipNetToPhysicalState |
+----------------------------------+--------------------------------+YANG Interface Data Nodes and Related IP-MIB Objects 🌸
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 8344; see
the RFC itself for full legal notices.";
revision 2018-02-22 {
description
"Updated to support NMDA.";
reference
"RFC 8344: A YANG Data Model for IP Management";
}
revision 2014-06-16 {
description
"Initial revision.";
reference
"RFC 7277: A YANG Data Model for IP Management";
}Okay bestie, the legal fine print is done, and now we're on the revision history 📜✨ The newest entry is from 2018-02-22, when the module was updated to support NMDA 💅 The very first one is the 2014-06-16 initial revision, which points back to RFC 7277 🌸
/*
* Features
*/
feature ipv4-non-contiguous-netmasks {
description
"Indicates support for configuring non-contiguous
subnet masks.";
}
feature ipv6-privacy-autoconf {
description
"Indicates support for privacy extensions for stateless address
autoconfiguration in IPv6.";
reference
"RFC 4941: Privacy Extensions for Stateless Address
Autoconfiguration in IPv6";
}
/*
* Typedefs
*/
typedef ip-address-origin {
type enumeration {
enum other {
description
"None of the following.";
}
enum static {
description
"Indicates that the address has been statically
configured -- for example, using the Network Configuration
Protocol (NETCONF) or a command line interface.";
}
enum dhcp {
description
"Indicates an address that has been assigned to this
system by a DHCP server.";
}
enum link-layer {
description
"Indicates an address created by IPv6 stateless
autoconfiguration that embeds a link-layer address in its
interface identifier.";
}
enum random {
description
"Indicates an address chosen by the system at
random, e.g., an IPv4 address within 169.254/16, a
temporary address as described in RFC 4941, or a
semantically opaque address as described in RFC 7217.";
reference
"RFC 4941: Privacy Extensions for Stateless Address
Autoconfiguration in IPv6
RFC 7217: A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless
Address Autoconfiguration (SLAAC)";
}
}
description
"The origin of an address.";
}
typedef neighbor-origin {
type enumeration {
enum other {
description
"None of the following.";
}
enum static {
description
"Indicates that the mapping has been statically
configured -- for example, using NETCONF or a command line
interface.";
}
enum dynamic {
description
"Indicates that the mapping has been dynamically resolved
using, for example, IPv4 ARP or the IPv6 Neighbor
Discovery protocol.";
}
}
description
"The origin of a neighbor entry.";
}Next up are the two features, the ones you turn on when your device supports them ✨ ipv4-non-contiguous-netmasks is for non-contiguous subnet masks, and ipv6-privacy-autoconf is for the privacy extensions for stateless address autoconfiguration in IPv6, which points to RFC 4941 🎀
Then we get to the typedefs, which are basically the little enum menus for where an address or neighbor entry came from 🦋 For addresses, ip-address-origin has five choices: other, static, dhcp, link-layer, and random. The random one is the iconic one, covering stuff like a 169.254/16 IPv4 address, a temporary address from RFC 4941, or a semantically opaque address from RFC 7217 🧚 For neighbors, neighbor-origin has three choices: other, static, and dynamic, and dynamic is the one that gets resolved through things like IPv4 ARP or the IPv6 Neighbor Discovery protocol 💜
/*
* Data nodes
*/
augment "/if:interfaces/if:interface" {
description
"IP parameters on interfaces.
If an interface is not capable of running IP, the server
must not allow the client to configure these parameters.";
container ipv4 {
presence
"Enables IPv4 unless the 'enabled' leaf
(which defaults to 'true') is set to 'false'";
description
"Parameters for the IPv4 address family.";
leaf enabled {
type boolean;
default true;
description
"Controls whether IPv4 is enabled or disabled on this
interface. When IPv4 is enabled, this interface is
connected to an IPv4 stack, and the interface can send
and receive IPv4 packets.";
}
leaf forwarding {
type boolean;
default false;
description
"Controls IPv4 packet forwarding of datagrams received by,
but not addressed to, this interface. IPv4 routers
forward datagrams. IPv4 hosts do not (except those
source-routed via the host).";
}
leaf mtu {
type uint16 {
range "68..max";
}
units "octets";
description
"The size, in octets, of the largest IPv4 packet that the
interface will send and receive.
The server may restrict the allowed values for this leaf,
depending on the interface's type.
If this leaf is not configured, the operationally used MTU
depends on the interface's type.";
reference
"RFC 791: Internet Protocol";
}
list address {
key "ip";
description
"The list of IPv4 addresses on the interface.";
leaf ip {
type inet:ipv4-address-no-zone;
description
"The IPv4 address on the interface.";
}
choice subnet {
mandatory true;
description
"The subnet can be specified as a prefix length or,
if the server supports non-contiguous netmasks, as
a netmask.";
leaf prefix-length {
type uint8 {
range "0..32";
}
description
"The length of the subnet prefix.";
}
leaf netmask {
if-feature ipv4-non-contiguous-netmasks;
type yang:dotted-quad;
description
"The subnet specified as a netmask.";
}
}
leaf origin {
type ip-address-origin;
config false;
description
"The origin of this address.";
}
}
list neighbor {
key "ip";
description
"A list of mappings from IPv4 addresses to
link-layer addresses.
Entries in this list in the intended configuration are
used as static entries in the ARP Cache.
In the operational state, this list represents the ARP
Cache.";
reference
"RFC 826: An Ethernet Address Resolution Protocol";
leaf ip {
type inet:ipv4-address-no-zone;
description
"The IPv4 address of the neighbor node.";
}
leaf link-layer-address {
type yang:phys-address;
mandatory true;
description
"The link-layer address of the neighbor node.";
}
leaf origin {
type neighbor-origin;
config false;
description
"The origin of this neighbor entry.";
}
}
}
container ipv6 {
presence
"Enables IPv6 unless the 'enabled' leaf
(which defaults to 'true') is set to 'false'";
description
"Parameters for the IPv6 address family.";
leaf enabled {
type boolean;
default true;
description
"Controls whether IPv6 is enabled or disabled on this
interface. When IPv6 is enabled, this interface is
connected to an IPv6 stack, and the interface can send
and receive IPv6 packets.";
}
leaf forwarding {
type boolean;
default false;
description
"Controls IPv6 packet forwarding of datagrams received by,
but not addressed to, this interface. IPv6 routers
forward datagrams. IPv6 hosts do not (except those
source-routed via the host).";
reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
Section 6.2.1, IsRouter";
}
leaf mtu {
type uint32 {
range "1280..max";
}
units "octets";
description
"The size, in octets, of the largest IPv6 packet that the
interface will send and receive.
The server may restrict the allowed values for this leaf,
depending on the interface's type.
If this leaf is not configured, the operationally used MTU
depends on the interface's type.";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification
Section 5";
}
list address {
key "ip";
description
"The list of IPv6 addresses on the interface.";Now we're in the augment zone, bestie 🌈 This is where the module hangs IP parameters onto each interface, and the description already gives a big warning: if an interface can't run IP, the server must not let the client configure these parameters 🙈
The ipv4 container is the first big one 💖 It has enabled (defaults to true), forwarding (defaults to false, and it covers the routers-versus-hosts thing), and mtu, which is measured in octets with a floor of 68 and points to RFC 791 🍓 Under it, the address list is keyed by ip, with a subnet choice that's mandatory and can be a prefix-length from 0 to 32, or a netmask if the non-contiguous feature is on 🦋 The neighbor list maps IPv4 addresses to link-layer addresses and is mandatory on that link-layer-address leaf. Its operational state is the ARP Cache, which is so iconic 💅
The ipv6 container is giving the same vibe 🧚 It has its own enabled and forwarding leaves, with forwarding pointing to Section 6.2.1, IsRouter, of RFC 4861. Its mtu is a uint32 with a floor of 1280, and it references RFC 8200 Section 5. The address list for IPv6 is starting right here, and I'm not gonna spoil the rest yet 👑 ✨
Okay so we're picking right back up inside the YANG module, bestie 💅 the address leaves are wrapping up and then the neighbor list shows up with its whole NUD state enum situation 🦋 Then we get the global knobs like duplicate address detection and autoconf, and the legacy IPv4 operational bits start loading at the bottom 🌸
leaf ip {
type inet:ipv6-address-no-zone;
description
"The IPv6 address on the interface.";
}
leaf prefix-length {
type uint8 {
range "0..128";
}
mandatory true;
description
"The length of the subnet prefix.";
}
leaf origin {
type ip-address-origin;
config false;
description
"The origin of this address.";
}
leaf status {
type enumeration {
enum preferred {
description
"This is a valid address that can appear as the
destination or source address of a packet.";
}
enum deprecated {
description
"This is a valid but deprecated address that should
no longer be used as a source address in new
communications, but packets addressed to such an
address are processed as expected.";
}
enum invalid {
description
"This isn't a valid address, and it shouldn't appear
as the destination or source address of a packet.";
}
enum inaccessible {
description
"The address is not accessible because the interface
to which this address is assigned is not
operational.";
}
enum unknown {
description
"The status cannot be determined for some reason.";
}
enum tentative {
description
"The uniqueness of the address on the link is being
verified. Addresses in this state should not be
used for general communication and should only be
used to determine the uniqueness of the address.";
}
enum duplicate {
description
"The address has been determined to be non-unique on
the link and so must not be used.";
}
enum optimistic {
description
"The address is available for use, subject to
restrictions, while its uniqueness on a link is
being verified.";
}
}
config false;
description
"The status of an address. Most of the states correspond
to states from the IPv6 Stateless Address
Autoconfiguration protocol.";
reference
"RFC 4293: Management Information Base for the
Internet Protocol (IP)
- IpAddressStatusTC
RFC 4862: IPv6 Stateless Address Autoconfiguration";
}
}
list neighbor {
key "ip";
description
"A list of mappings from IPv6 addresses to
link-layer addresses.
Entries in this list in the intended configuration are
used as static entries in the Neighbor Cache.
In the operational state, this list represents the
Neighbor Cache.";
reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6)";
leaf ip {
type inet:ipv6-address-no-zone;
description
"The IPv6 address of the neighbor node.";
}
leaf link-layer-address {
type yang:phys-address;
mandatory true;
description
"The link-layer address of the neighbor node.
In the operational state, if the neighbor's 'state' leaf
is 'incomplete', this leaf is not instantiated.";
}
leaf origin {
type neighbor-origin;
config false;
description
"The origin of this neighbor entry.";
}
leaf is-router {
type empty;
config false;
description
"Indicates that the neighbor node acts as a router.";
}
leaf state {
type enumeration {
enum incomplete {
description
"Address resolution is in progress, and the
link-layer address of the neighbor has not yet been
determined.";
}
enum reachable {
description
"Roughly speaking, the neighbor is known to have been
reachable recently (within tens of seconds ago).";
}
enum stale {
description
"The neighbor is no longer known to be reachable, but
until traffic is sent to the neighbor no attempt
should be made to verify its reachability.";
}
enum delay {
description
"The neighbor is no longer known to be reachable, and
traffic has recently been sent to the neighbor.
Rather than probe the neighbor immediately, however,
delay sending probes for a short while in order to
give upper-layer protocols a chance to provide
reachability confirmation.";
}
enum probe {
description
"The neighbor is no longer known to be reachable, and
unicast Neighbor Solicitation probes are being sent
to verify reachability.";
}
}
config false;
description
"The Neighbor Unreachability Detection state of this
entry.";
reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
Section 7.3.2";
}
}
leaf dup-addr-detect-transmits {
type uint32;
default 1;
description
"The number of consecutive Neighbor Solicitation messages
sent while performing Duplicate Address Detection on a
tentative address. A value of zero indicates that
Duplicate Address Detection is not performed on
tentative addresses. A value of one indicates a single
transmission with no follow-up retransmissions.";
reference
"RFC 4862: IPv6 Stateless Address Autoconfiguration";
}
container autoconf {
description
"Parameters to control the autoconfiguration of IPv6
addresses, as described in RFC 4862.";
reference
"RFC 4862: IPv6 Stateless Address Autoconfiguration";
leaf create-global-addresses {
type boolean;
default true;
description
"If enabled, the host creates global addresses as
described in RFC 4862.";
reference
"RFC 4862: IPv6 Stateless Address Autoconfiguration
Section 5.5";
}
leaf create-temporary-addresses {
if-feature ipv6-privacy-autoconf;
type boolean;
default false;
description
"If enabled, the host creates temporary addresses as
described in RFC 4941.";
reference
"RFC 4941: Privacy Extensions for Stateless Address
Autoconfiguration in IPv6";
}
leaf temporary-valid-lifetime {
if-feature ipv6-privacy-autoconf;
type uint32;
units "seconds";
default 604800;
description
"The time period during which the temporary address
is valid.";
reference
"RFC 4941: Privacy Extensions for Stateless Address
Autoconfiguration in IPv6
- TEMP_VALID_LIFETIME";
}
leaf temporary-preferred-lifetime {
if-feature ipv6-privacy-autoconf;
type uint32;
units "seconds";
default 86400;
description
"The time period during which the temporary address is
preferred.";
reference
"RFC 4941: Privacy Extensions for Stateless Address
Autoconfiguration in IPv6
- TEMP_PREFERRED_LIFETIME";
}
}
}
}
/*
* Legacy operational state data nodes
*/
augment "/if:interfaces-state/if:interface" {
status deprecated;
description
"Data nodes for the operational state of IP on interfaces.";
container ipv4 {
presence
"Present if IPv4 is enabled on this interface";
config false;
status deprecated;
description
"Interface-specific parameters for the IPv4 address family.";
leaf forwarding {
type boolean;
status deprecated;
description
"Indicates whether IPv4 packet forwarding is enabled or
disabled on this interface.";
}
leaf mtu {
type uint16 {
range "68..max";
}
units "octets";
status deprecated;
description
"The size, in octets, of the largest IPv4 packet that the
interface will send and receive.";
reference
"RFC 791: Internet Protocol";
}
list address {
key "ip";
status deprecated;
description
"The list of IPv4 addresses on the interface.";
leaf ip {
type inet:ipv4-address-no-zone;
status deprecated;
description
"The IPv4 address on the interface.";
}
choice subnet {
status deprecated;
description
"The subnet can be specified as a prefix length or,
if the server supports non-contiguous netmasks, as
a netmask.";
leaf prefix-length {
type uint8 {
range "0..32";
}
status deprecated;
description
"The length of the subnet prefix.";
}
leaf netmask {
if-feature ipv4-non-contiguous-netmasks;
type yang:dotted-quad;
status deprecated;
description
"The subnet specified as a netmask.";
}
}
leaf origin {
type ip-address-origin;
status deprecated;
description
"The origin of this address.";
}
}
list neighbor {
key "ip";
status deprecated;
description
"A list of mappings from IPv4 addresses to
link-layer addresses.
This list represents the ARP Cache.";
reference
"RFC 826: An Ethernet Address Resolution Protocol";Next up: the IPv4 neighbor list keeps going and we get into the rest of the legacy stuff 🧚💜
leaf ip {
type inet:ipv4-address-no-zone;
status deprecated;
description
"The IPv4 address of the neighbor node.";
}
leaf link-layer-address {
type yang:phys-address;
status deprecated;
description
"The link-layer address of the neighbor node.";
}
leaf origin {
type neighbor-origin;
status deprecated;
description
"The origin of this neighbor entry.";
}
}
}
container ipv6 {
presence
"Present if IPv6 is enabled on this interface";
config false;
status deprecated;
description
"Parameters for the IPv6 address family.";
leaf forwarding {
type boolean;
default false;
status deprecated;
description
"Indicates whether IPv6 packet forwarding is enabled or
disabled on this interface.";
reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
Section 6.2.1, IsRouter";
}
leaf mtu {
type uint32 {
range "1280..max";
}
units "octets";
status deprecated;
description
"The size, in octets, of the largest IPv6 packet that the
interface will send and receive.";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification
Section 5";
}
list address {
key "ip";
status deprecated;
description
"The list of IPv6 addresses on the interface.";
leaf ip {
type inet:ipv6-address-no-zone;
status deprecated;
description
"The IPv6 address on the interface.";
}
leaf prefix-length {
type uint8 {
range "0..128";
}
mandatory true;
status deprecated;
description
"The length of the subnet prefix.";
}
leaf origin {
type ip-address-origin;
status deprecated;
description
"The origin of this address.";
}
leaf status {
type enumeration {
enum preferred {
description
"This is a valid address that can appear as the
destination or source address of a packet.";
}
enum deprecated {
description
"This is a valid but deprecated address that should
no longer be used as a source address in new
communications, but packets addressed to such an
address are processed as expected.";
}
enum invalid {
description
"This isn't a valid address, and it shouldn't appear
as the destination or source address of a packet.";
}
enum inaccessible {
description
"The address is not accessible because the interface
to which this address is assigned is not
operational.";
}
enum unknown {
description
"The status cannot be determined for some reason.";
}
enum tentative {
description
"The uniqueness of the address on the link is being
verified. Addresses in this state should not be
used for general communication and should only be
used to determine the uniqueness of the address.";
}
enum duplicate {
description
"The address has been determined to be non-unique on
the link and so must not be used.";
}
enum optimistic {
description
"The address is available for use, subject to
restrictions, while its uniqueness on a link is
being verified.";
}
}
status deprecated;
description
"The status of an address. Most of the states correspond
to states from the IPv6 Stateless Address
Autoconfiguration protocol.";
reference
"RFC 4293: Management Information Base for the
Internet Protocol (IP)
- IpAddressStatusTC
RFC 4862: IPv6 Stateless Address Autoconfiguration";
}
}
list neighbor {
key "ip";
status deprecated;
description
"A list of mappings from IPv6 addresses to
link-layer addresses.
This list represents the Neighbor Cache.";
reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6)";
leaf ip {
type inet:ipv6-address-no-zone;
status deprecated;
description
"The IPv6 address of the neighbor node.";
}
leaf link-layer-address {
type yang:phys-address;
status deprecated;
description
"The link-layer address of the neighbor node.";
}
leaf origin {
type neighbor-origin;
status deprecated;
description
"The origin of this neighbor entry.";
}
leaf is-router {
type empty;
status deprecated;
description
"Indicates that the neighbor node acts as a router.";
}
leaf state {
type enumeration {
enum incomplete {
description
"Address resolution is in progress, and the
link-layer address of the neighbor has not yet been
determined.";
}
enum reachable {
description
"Roughly speaking, the neighbor is known to have been
reachable recently (within tens of seconds ago).";
}
enum stale {
description
"The neighbor is no longer known to be reachable, but
until traffic is sent to the neighbor no attempt
should be made to verify its reachability.";
}
enum delay {
description
"The neighbor is no longer known to be reachable, and
traffic has recently been sent to the neighbor.
Rather than probe the neighbor immediately, however,
delay sending probes for a short while in order to
give upper-layer protocols a chance to provide
reachability confirmation.";
}
enum probe {
description
"The neighbor is no longer known to be reachable, and
unicast Neighbor Solicitation probes are being sent
to verify reachability.";
}
}
status deprecated;
description
"The Neighbor Unreachability Detection state of this
entry.";
reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
Section 7.3.2";
}
}
}
}
}
<CODE ENDS>5. IANA Considerations 🦋
okay so this bit is about registrations 💅 this document registers a URI in the "IETF XML Registry" [RFC3688]. following the format in RFC 3688, the registration has been made, and it looks like this ✨
URI: urn:ietf:params:xml:ns:yang:ietf-ip
Registrant Contact: The NETMOD WG of the IETF.
XML: N/A; the requested URI is an XML namespace.this document also registers a YANG module in the "YANG Module Names" registry [RFC6020] 🌸
Name: ietf-ip
Namespace: urn:ietf:params:xml:ns:yang:ietf-ip
Prefix: ip
Reference: RFC 83446. Security Considerations 🔐
bestie, this part is serious, so we're going full dramatic 😭 the YANG module in this document defines a schema for data that's meant to be reached through network management protocols like NETCONF [RFC6241] or RESTCONF [RFC8040]. the lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport there is Secure Shell (SSH) [RFC6242]. the lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport there is TLS [RFC5246].
the NETCONF access control model [RFC8341] gives you the tools to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all the available NETCONF or RESTCONF protocol operations and content 🔒
there are a bunch of data nodes in this module that can be written, created, or deleted (that's config true, which is the default). these might be sensitive or vulnerable in some network environments. write operations (like edit-config) to them without proper protection can seriously mess with network operations 🚨
here's the list of subtrees and data nodes, plus why each one is sensitive 👇
ipv4/enabledandipv6/enabled: these leafs turn IPv4 and IPv6 on or off on a specific interface. if an attacker turns a protocol on, they might create an unsecured path into a node (or through it, if routing is also enabled) 💀. if they turn a protocol off, they might force packets to take some other interface, or cut off access to some or all of the network over that protocol 🙈ipv4/addressandipv6/address: these lists hold the configured IP addresses on an interface. if someone modifies them, an attacker can make a node ignore messages meant for it, or accept (at least at the IP layer) messages it would otherwise ignore. filtering or security associations may reduce the potential damage in the latter case 🛡️ipv4/forwardingandipv6/forwarding: these leafs let a client enable or disable the forwarding functions on the entity. disabling them could let an attacker deny service to users 😤. enabling them could open a conduit into an area 🚪. that might make the area provide transit for packets it shouldn't carry, or let the attacker into the area while bypassing security safeguards 💔ipv6/autoconf: the leafs in this branch control autoconfiguration of IPv6 addresses and, in particular, whether or not temporary addresses are used. if someone changes those leafs, they might impact the addresses a node uses and, indirectly, the privacy of the users on that node 🫣ipv4/mtuandipv6/mtu: setting these leafs to very small values can be used to slow down interfaces 🐢
7. References 📚
the reference list picks up in the next part, bestie 🫶
7.1. Normative References ✨
okay bestie, these are the docs this spec literally can't function without 💖 Every entry is copied exactly below, DOIs and all 🔥
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[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>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[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>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[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>.
[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>.7.2. Informative References 🦋
these ones are more like "good to know" reading, not required reading 🌸
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>.
[RFC4293] Routhier, S., Ed., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293,
April 2006, <https://www.rfc-editor.org/info/rfc4293>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[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>.
[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>.Appendix A. Example: NETCONF <get-config> Reply 🎀
okay this is the fun part, we get to see what an actual reply looks like! 🧚 This section gives an example of a reply to the NETCONF <get-config> request for the running configuration datastore for a device that implements the data model defined in this document.
The XML [W3C.REC-xml-20081126] snippets that follow in this section and in Appendix B are provided as examples only. just examples, not gospel, so don't copy-paste them into production and blame me 😭
<rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<data>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<address>
<ip>192.0.2.1</ip>
<prefix-length>24</prefix-length>
</address>
</ipv4>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<mtu>1280</mtu>
<address>
<ip>2001:db8::10</ip>
<prefix-length>32</prefix-length>
</address>
<dup-addr-detect-transmits>0</dup-addr-detect-transmits>
</ipv6>
</interface>
</interfaces>
</data>
</rpc-reply>Appendix B. Example: NETCONF <get-data> Reply 🍓
this one is giving operational state realness 💅 This section gives an example of a reply to the NETCONF <get-data> request for the operational state datastore for a device that implements the data model defined in this document.
This example uses the "origin" annotation, which is defined in the module "ietf-origin" [RFC8342].
<rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores">
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<interface or:origin="or:intended">
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<!-- other parameters from ietf-interfaces omitted -->
<ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<enabled or:origin="or:default">true</enabled>
<forwarding or:origin="or:default">false</forwarding>
<mtu or:origin="or:system">1500</mtu>
<address>
<ip>192.0.2.1</ip>
<prefix-length>24</prefix-length>
<origin>static</origin>
</address>
<neighbor or:origin="or:learned">
<ip>192.0.2.2</ip>
<link-layer-address>
00:00:5E:00:53:AB
</link-layer-address>
</neighbor>
</ipv4>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<enabled or:origin="or:default">true</enabled>
<forwarding or:origin="or:default">false</forwarding>
<mtu>1280</mtu>
<address>
<ip>2001:db8::10</ip>
<prefix-length>32</prefix-length>
<origin>static</origin>
<status>preferred</status>
</address>
<address or:origin="or:learned">
<ip>2001:db8::1:100</ip>
<prefix-length>32</prefix-length>
<origin>dhcp</origin>
<status>preferred</status>
</address>
<dup-addr-detect-transmits>0</dup-addr-detect-transmits>
<neighbor or:origin="or:learned">
<ip>2001:db8::1</ip>
<link-layer-address>
00:00:5E:00:53:AB
</link-layer-address>
<origin>dynamic</origin>
<is-router/>
<state>reachable</state>
</neighbor>
<neighbor or:origin="or:learned">
<ip>2001:db8::4</ip>
<origin>dynamic</origin>
<state>incomplete</state>
</neighbor>
</ipv6>
</interface>
</interfaces>
</data>
</rpc-reply>Acknowledgments 🫶
big thank yous from the author to Jeffrey Lange, Ladislav Lhotka, Juergen Schoenwaelder, and Dave Thaler for their helpful comments 💜
Author's Address 🌈
Martin Bjorklund Tail-f Systems
Email: mbj@tail-f.com
📦 where this page comes from
- ietf: rfc8344 2018-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms