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 ^RFC7950^ 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 ^I-D.ietf-netmod-rfc7223bis^.
This version of the IP data model supports the Network Management Datastore Architecture (NMDA) ^I-D.ietf-netmod-revised-datastores^.
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, ^RFC2119^ ^RFC8174^ when, and only when, they appear in all capitals, as shown here.
The following terms are defined in ^I-D.ietf-netmod-revised-datastores^ 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 ^RFC7950^ and are not redefined here:
- augment
- data model
- data node
The terminology for describing YANG data models is found in ^RFC7950^.
Tree diagrams used in this document follow the notation defined in ^I-D.ietf-netmod-yang-tree-diagrams^.
This document defines the YANG module “ietf-ip”, which augments the “interface” and “interface-state” lists defined in the “ietf-interfaces” module ^I-D.ietf-netmod-rfc7223bis^ with IP-specific data nodes.
The data model has the following structure for IP data nodes per interface, excluding the deprecated data nodes:
!! include-figure ietf-ip.tree
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 ^RFC4293^, 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 ^RFC8022^.
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 Interface Data Nodes and Related IP-MIB Objects
| YANG data node in /if:interfaces/if:interface | IP-MIB object |
|---|---|
| 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 |
This module imports typedefs from ^RFC6991^ and ^I-D.ietf-netmod-rfc7223bis^, and it references ^RFC0791^, ^RFC0826^, ^RFC2460^, ^RFC4861^, ^RFC4862^, ^RFC4941^ and ^RFC7217^.
RFC Ed.: update the date below with the date of RFC publication and remove this note.
!! include-figure ietf-ip.yang extract-to=”ietf-ip@2018-01-09.yang”
This document registers a URI in the “IETF XML Registry” ^RFC3688^. Following the format in RFC 3688, the following registration has been made.
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 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 7277
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 ^RFC6241^ or RESTCONF ^RFC8040^. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) ^RFC6242^. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS ^RFC5246^.
The NETCONF access control model ^RFC6536^ 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:
= ipv4/enabled and ipv6/enabled: 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. = ipv4/address and ipv6/address: 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. = ipv4/forwarding and ipv6/forwarding: 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. = ipv6/autoconf: 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. = ipv4/mtu and ipv6/mtu: 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.
*! start-appendix
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.
!! include-figure ex-get-config-reply.xml
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” ^I-D.ietf-netmod-revised-datastores^.
!! include-figure ex-get-data-reply.load
#*! start-back # #* Normative References
{{document: name ; ipr trust200902; category std; references references.xml; obsoletes rfc7277; title “A YANG Data Model for IP Management”; abbreviation “YANG IP Management”; contributor “author:Martin Bjorklund:Tail-f Systems:mbj@tail-f.com”; }}