A YANG Data Model for IP ManagementTail-f Systemsmbj@tail-f.com
This document defines a YANG data model for management of IP
implementations. The data model includes configuration and system
state.
The YANG model in this document conforms to the Network Management
Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.
This document obsoletes RFC 7277.
This document defines a YANG data model for
management of IP implementations.
The data model covers configuration of per-interface IPv4 and IPv6
parameters, and mappings of IP addresses to link-layer addresses. It
also provides information about which IP addresses are operationally
used, and which link-layer mappings exist. Per-interface parameters
are added through augmentation of the interface data model defined in
.
This version of the IP data model supports the Network
Management Datastore Architecture (NMDA)
.
The "ipv4" and "ipv6" subtrees with "config false" data nodes in the
"/interfaces‑state/interface" subtree are deprecated. All "config
false" data nodes are now present in the "ipv4" and "ipv6" subtrees in
the "/interfaces/interface" subtree.
Servers that do not implement NMDA, or that wish to support clients
that do not implement NMDA, MAY implement the deprecated "ipv4" and
"ipv6" subtrees in the "/interfaces‑state/interface" subtree.
The keywords "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, when, and only when, they appear in all capitals,
as shown here.
The following terms are defined in
and are not redefined here:
client
server
configuration
system state
intended configuration
running configuration datastore
operational state
operational state datastore
The following terms are defined in and are not redefined
here:
augment
data model
data node
The terminology for describing YANG data models is found in
.
Tree diagrams used in this document follow the notation defined in
.
This document defines the YANG module "ietf‑ip", which augments the
"interface" and "interface‑state" lists defined in the
"ietf‑interfaces" module with
IP-specific data nodes.
The data model has the following structure for IP data nodes per
interface, excluding the deprecated data nodes:
The data model defines two containers per interface --
"ipv4" and "ipv6", representing the IPv4 and IPv6 address families.
In each container, there is a leaf "enabled" that controls whether or
not the address family is enabled on that interface, and a leaf
"forwarding" that controls whether or not IP packet forwarding for the
address family is enabled on the interface. In each container, there
is also a list of addresses, and a list of mappings from IP addresses
to link-layer addresses.
If the device implements the IP-MIB , each entry in the
"ipv4/address" and "ipv6/address" lists is mapped to one
ipAddressEntry, where the ipAddressIfIndex refers to the "address"
entry's interface.
The IP-MIB defines objects to control IPv6 Router Advertisement
messages. The corresponding YANG data nodes are defined in .
The entries in "ipv4/neighbor" and "ipv6/neighbor" are mapped to
ipNetToPhysicalTable.
The following table lists the YANG data nodes with corresponding objects
in the IP-MIB.
YANG data node in /if:interfaces/if:interfaceIP-MIB objectipv4ipv4InterfaceEnableStatusipv4/enabledipv4InterfaceEnableStatusipv4/addressipAddressEntryipv4/address/ipipAddressAddrType ipAddressAddripv4/neighboripNetToPhysicalEntryipv4/neighbor/ipipNetToPhysicalNetAddressType ipNetToPhysicalNetAddressipv4/neighbor/link-layer-addressipNetToPhysicalPhysAddressipv4/neighbor/originipNetToPhysicalTypeipv6ipv6InterfaceEnableStatusipv6/enabledipv6InterfaceEnableStatusipv6/forwardingipv6InterfaceForwardingipv6/addressipAddressEntryipv6/address/ipipAddressAddrType ipAddressAddripv4/address/originipAddressOriginipv6/address/statusipAddressStatusipv6/neighboripNetToPhysicalEntryipv6/neighbor/ipipNetToPhysicalNetAddressType ipNetToPhysicalNetAddressipv6/neighbor/link-layer-addressipNetToPhysicalPhysAddressipv6/neighbor/originipNetToPhysicalTypeipv6/neighbor/stateipNetToPhysicalState
This module imports typedefs from and
, and it references , ,
, , , and
.
RFC Ed.: update the date below with the date of RFC publication and
remove this note.
<CODE BEGINS> file "ietf-ip@2018-01-09.yang"<CODE ENDS>
This document registers a URI in the "IETF XML Registry"
. Following the format in RFC 3688, the following
registration has been made.
This document registers a YANG module in the "YANG Module Names"
registry .
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF or RESTCONF . The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) . The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
.
The NETCONF access control model provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in the YANG module which are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) to
these data nodes without proper protection can have a negative effect
on network operations. These are the subtrees and data nodes and
their sensitivity/vulnerability:
These leafs are used to enable or disable IPv4 and IPv6 on a specific
interface. By enabling a protocol on an interface, an attacker might
be able to create an unsecured path into a node (or through it if
routing is also enabled). By disabling a protocol on an interface, an
attacker might be able to force packets to be routed through some
other interface or deny access to some or all of the network via that
protocol.
These lists specify the configured IP addresses on an interface. By
modifying this information, an attacker can cause a node to either
ignore messages destined to it or accept (at least at the IP layer)
messages it would otherwise ignore. The use of filtering or security
associations may reduce the potential damage in the latter case.
These leafs allow a client to enable or disable the forwarding functions
on the entity. By disabling the forwarding functions, an attacker would
possibly be able to deny service to users. By enabling the forwarding
functions, an attacker could open a conduit into an area. This might
result in the area providing transit for packets it shouldn't, or it might
allow the attacker access to the area, bypassing security safeguards.
The leafs in this branch control the autoconfiguration
of IPv6 addresses and, in particular, whether or not temporary addresses are
used. By modifying the corresponding leafs, an attacker might
impact the addresses used by a node and thus indirectly the
privacy of the users using the node.
Setting these leafs to very small values can be used to slow down
interfaces.
The author wishes to thank Jeffrey Lange, Ladislav Lhotka, Juergen
Schoenwaelder, and Dave Thaler for their helpful comments.
Internet ProtocolKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Internet Protocol, Version 6 (IPv6) SpecificationThis document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Neighbor Discovery for IP version 6 (IPv6)This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]IPv6 Stateless Address AutoconfigurationThis document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]Privacy Extensions for Stateless Address Autoconfiguration in IPv6Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.A YANG Data Model for Interface ManagementThis document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). This document obsoletes RFC 7223.Network Management Datastore ArchitectureDatastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as NETCONF and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model.Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet HardwareThe purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard.Management Information Base for the Internet Protocol (IP)This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF) Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK]A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).A YANG Data Model for Routing ManagementThis document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.YANG Tree DiagramsThis document captures the current syntax used in YANG module Tree Diagrams. The purpose of the document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.
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.
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" .