A YANG Data Model for IP ManagementTail-f Systemsmbj@tail-f.comThis document defines a YANG data model for management of IP
implementations. The data model includes configuration data and state
data. 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
. The following terms are defined in and are not
redefined here:
client
configuration data
server
state data
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
.
A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these
diagrams is as follows:
Brackets "[" and "]" enclose list keys.
Abbreviations before data node names: "rw" means configuration
data (read-write), and "ro" means state data (read-only).
Symbols after data node names: "?" means an optional node,
"!" means
a presence container, and "*" denotes a list and leaf-list.
Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
Ellipsis ("...") stands for contents of subtrees that are not shown.
This document defines the YANG module "ietf&nbhy;ip", which
augments the "interface" and "interface&nbhy;state"
lists defined in the "ietf&nbhy;interfaces" module with IP-specific data nodes, and also adds IP-specific
state data.
The data model has the following structure for IP configuration per
interface:
The data model defines two configuration 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 configured addresses, and a list of configured
mappings from IP addresses to link-layer addresses.
The data model has the following structure for IP state per
interface:
The data model defines two state containers per interface -- "ipv4"
and "ipv6", representing the IPv4 and IPv6 address families.
In each container, there is a leaf "forwarding" that indicates
whether or not IP packet forwarding is enabled on that interface. In each
container, there is also a list of all addresses in use and a list of
known 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 tables list the YANG data nodes with corresponding objects
in the IP-MIB.
YANG data node in /if:interfaces/if:interfaceIP-MIB objectipv4/enabledipv4InterfaceEnableStatusipv4/addressipAddressEntryipv4/address/ipipAddressAddrType ipAddressAddripv4/neighboripNetToPhysicalEntryipv4/neighbor/ipipNetToPhysicalNetAddressType ipNetToPhysicalNetAddressipv4/neighbor/link-layer-addressipNetToPhysicalPhysAddressipv6/enabledipv6InterfaceEnableStatusipv6/forwardingipv6InterfaceForwardingipv6/addressipAddressEntryipv6/address/ipipAddressAddrType ipAddressAddripv6/neighboripNetToPhysicalEntryipv6/neighbor/link-layer-addressipNetToPhysicalPhysAddressipv6/neighbor/originipNetToPhysicalTypeYANG data node in
/if:interfaces&nbhy;state/if:interfaceIP-MIB objectipv4ipv4InterfaceEnableStatusipv4/addressipAddressEntryipv4/address/ipipAddressAddrType ipAddressAddripv4/address/originipAddressOriginipv4/neighboripNetToPhysicalEntryipv4/neighbor/ipipNetToPhysicalNetAddressType ipNetToPhysicalNetAddressipv4/neighbor/link-layer-addressipNetToPhysicalPhysAddressipv4/neighbor/originipNetToPhysicalTypeipv6ipv6InterfaceEnableStatusipv6/forwardingipv6InterfaceForwardingipv6/addressipAddressEntryipv6/address/ipipAddressAddrType ipAddressAddripv6/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
.
<CODE BEGINS> file "ietf-ip@2014-06-10.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 defined in this memo is designed to be accessed via
the NETCONF protocol . The lowest NETCONF layer is
the secure transport layer and the mandatory-to-implement secure transport
is SSH . The NETCONF access control model provides the means to restrict access for particular
NETCONF users to a pre-configured subset of all available NETCONF
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.
Extensible Markup Language (XML) 1.0 (Fifth Edition)A YANG Data Model for Routing Management
This section gives an example of a reply to the NETCONF <get> request
for a device that implements the data model defined in this document.
The example is written in XML .