draft-ietf-netmod-rfc7277bis-03.txt   rfc8344.txt 
Network Working Group M. Bjorklund Internet Engineering Task Force (IETF) M. Bjorklund
Internet-Draft Tail-f Systems Request for Comments: 8344 Tail-f Systems
Obsoletes: rfc7277 (if approved) January 11, 2018 Obsoletes: 7277 March 2018
Intended status: Standards Track Category: Standards Track
Expires: July 15, 2018 ISSN: 2070-1721
A YANG Data Model for IP Management A YANG Data Model for IP Management
draft-ietf-netmod-rfc7277bis-03
Abstract Abstract
This document defines a YANG data model for management of IP This document defines a YANG data model for management of IP
implementations. The data model includes configuration and system implementations. The data model includes configuration and system
state. state.
The YANG model in this document conforms to the Network Management The YANG data model in this document conforms to the Network
Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. Management Datastore Architecture defined in RFC 8342.
This document obsoletes RFC 7277. This document obsoletes RFC 7277.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on July 15, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8344.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................2
1.1. Summary of Changes from RFC 7277 . . . . . . . . . . . . 2 1.1. Summary of Changes from RFC 7277 ...........................2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology ................................................3
1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Tree Diagrams ..............................................3
2. IP Data Model . . . . . . . . . . . . . . . . . . . . . . . . 4 2. IP Data Model ...................................................4
3. Relationship to the IP-MIB . . . . . . . . . . . . . . . . . 6 3. Relationship to the IP-MIB ......................................5
4. IP Management YANG Module . . . . . . . . . . . . . . . . . . 7 4. IP Management YANG Module .......................................7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations ............................................27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations ........................................27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 7. References .....................................................29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1. Normative References ......................................29
8.1. Normative References . . . . . . . . . . . . . . . . . . 27 7.2. Informative References ....................................31
8.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Example: NETCONF <get-config> Reply ...................32
Appendix A. Example: NETCONF <get-config> reply . . . . . . . . 30 Appendix B. Example: NETCONF <get-data> Reply .....................33
Appendix B. Example: NETCONF <get-data> Reply . . . . . . . . . 30 Acknowledgments ...................................................34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 Author's Address ..................................................34
1. Introduction 1. Introduction
This document defines a YANG [RFC7950] data model for management of This document defines a YANG data model [RFC7950] for management of
IP implementations. IP implementations.
The data model covers configuration of per-interface IPv4 and IPv6 The data model covers configuration of per-interface IPv4 and IPv6
parameters, and mappings of IP addresses to link-layer addresses. It parameters as well as mappings of IP addresses to link-layer
also provides information about which IP addresses are operationally addresses. It also provides information about which IP addresses are
used, and which link-layer mappings exist. Per-interface parameters operationally used and which link-layer mappings exist.
are added through augmentation of the interface data model defined in Per-interface parameters are added through augmentation of the
[I-D.ietf-netmod-rfc7223bis]. interface data model defined in [RFC8343].
This version of the IP data model supports the Network Management This version of the IP data model supports the Network Management
Datastore Architecture (NMDA) [I-D.ietf-netmod-revised-datastores]. Datastore Architecture (NMDA) [RFC8342].
1.1. Summary of Changes from RFC 7277 1.1. Summary of Changes from RFC 7277
The "ipv4" and "ipv6" subtrees with "config false" data nodes in the The "ipv4" and "ipv6" subtrees with "config false" data nodes in the
"/interfaces-state/interface" subtree are deprecated. All "config "/interfaces-state/interface" subtree are deprecated. All
false" data nodes are now present in the "ipv4" and "ipv6" subtrees "config false" data nodes are now present in the "ipv4" and "ipv6"
in the "/interfaces/interface" subtree. subtrees in the "/interfaces/interface" subtree.
Servers that do not implement NMDA, or that wish to support clients Servers that do not implement NMDA or that wish to support clients
that do not implement NMDA, MAY implement the deprecated "ipv4" and that do not implement NMDA MAY implement the deprecated "ipv4" and
"ipv6" subtrees in the "/interfaces-state/interface" subtree. "ipv6" subtrees in the "/interfaces-state/interface" subtree.
1.2. Terminology 1.2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14, [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are defined in The following terms are defined in [RFC8342] and are not redefined
[I-D.ietf-netmod-revised-datastores] and are not redefined here: here:
o client o client
o server o server
o configuration o configuration
o system state o system state
o intended configuration o intended configuration
skipping to change at page 3, line 51 skipping to change at page 3, line 47
o data model o data model
o data node o data node
The terminology for describing YANG data models is found in The terminology for describing YANG data models is found in
[RFC7950]. [RFC7950].
1.3. Tree Diagrams 1.3. Tree Diagrams
Tree diagrams used in this document follow the notation defined in Tree diagrams used in this document follow the notation defined in
[I-D.ietf-netmod-yang-tree-diagrams]. [RFC8340].
2. IP Data Model 2. IP Data Model
This document defines the YANG module "ietf-ip", which augments the This document defines the YANG module "ietf-ip", which augments the
"interface" and "interface-state" lists defined in the "interface" lists defined in the "ietf-interfaces" module [RFC8343]
"ietf-interfaces" module [I-D.ietf-netmod-rfc7223bis] with IP- with IP-specific data nodes.
specific data nodes.
The data model has the following structure for IP data nodes per The data model has the following structure for IP data nodes per
interface, excluding the deprecated data nodes: interface, excluding the deprecated data nodes:
module: ietf-ip module: ietf-ip
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw ipv4! +--rw ipv4!
| +--rw enabled? boolean | +--rw enabled? boolean
| +--rw forwarding? boolean | +--rw forwarding? boolean
| +--rw mtu? uint16 | +--rw mtu? uint16
skipping to change at page 6, line 6 skipping to change at page 5, line 19
| {ipv6-privacy-autoconf}? | {ipv6-privacy-autoconf}?
+--rw temporary-preferred-lifetime? uint32 +--rw temporary-preferred-lifetime? uint32
{ipv6-privacy-autoconf}? {ipv6-privacy-autoconf}?
The data model defines two containers per interface -- "ipv4" and The data model defines two containers per interface -- "ipv4" and
"ipv6", representing the IPv4 and IPv6 address families. In each "ipv6", representing the IPv4 and IPv6 address families. In each
container, there is a leaf "enabled" that controls whether or not the container, there is a leaf "enabled" that controls whether or not the
address family is enabled on that interface, and a leaf "forwarding" address family is enabled on that interface, and a leaf "forwarding"
that controls whether or not IP packet forwarding for the address that controls whether or not IP packet forwarding for the address
family is enabled on the interface. In each container, there is also 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 a list of addresses and a list of mappings from IP addresses to
link-layer addresses. link-layer addresses.
3. Relationship to the IP-MIB 3. Relationship to the IP-MIB
If the device implements the IP-MIB [RFC4293], each entry in the If the device implements the IP-MIB [RFC4293], each entry in the
"ipv4/address" and "ipv6/address" lists is mapped to one "ipv4/address" and "ipv6/address" lists is mapped to one
ipAddressEntry, where the ipAddressIfIndex refers to the "address" ipAddressEntry, where the ipAddressIfIndex refers to the "address"
entry's interface. entry's interface.
The IP-MIB defines objects to control IPv6 Router Advertisement The IP-MIB defines objects to control IPv6 Router Advertisement
skipping to change at page 7, line 39 skipping to change at page 7, line 7
| | ipNetToPhysicalNetAddress | | | ipNetToPhysicalNetAddress |
| ipv6/neighbor/link-layer-address | ipNetToPhysicalPhysAddress | | ipv6/neighbor/link-layer-address | ipNetToPhysicalPhysAddress |
| ipv6/neighbor/origin | ipNetToPhysicalType | | ipv6/neighbor/origin | ipNetToPhysicalType |
| ipv6/neighbor/state | ipNetToPhysicalState | | ipv6/neighbor/state | ipNetToPhysicalState |
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
YANG Interface Data Nodes and Related IP-MIB Objects YANG Interface Data Nodes and Related IP-MIB Objects
4. IP Management YANG Module 4. IP Management YANG Module
This module imports typedefs from [RFC6991] and This module imports typedefs from [RFC6991] and [RFC8343], and it
[I-D.ietf-netmod-rfc7223bis], and it references [RFC0791], [RFC0826], references [RFC791], [RFC826], [RFC4861], [RFC4862], [RFC4941],
[RFC2460], [RFC4861], [RFC4862], [RFC4941] and [RFC7217]. [RFC7217], and [RFC8200].
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 BEGINS> file "ietf-ip@2018-02-22.yang"
module ietf-ip { module ietf-ip {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ip"; namespace "urn:ietf:params:xml:ns:yang:ietf-ip";
prefix ip; prefix ip;
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
skipping to change at page 8, line 18 skipping to change at page 7, line 31
prefix inet; prefix inet;
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
organization organization
"IETF NETMOD (Network Modeling) Working Group"; "IETF NETMOD (Network Modeling) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
Editor: Martin Bjorklund Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>"; <mailto:mbj@tail-f.com>";
description description
"This module contains a collection of YANG definitions for "This module contains a collection of YANG definitions for
managing IP implementations. managing IP implementations.
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 8344; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2018-01-09 { revision 2018-02-22 {
description description
"Updated to support NMDA."; "Updated to support NMDA.";
reference reference
"RFC XXXX: A YANG Data Model for IP Management"; "RFC 8344: A YANG Data Model for IP Management";
} }
revision 2014-06-16 { revision 2014-06-16 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 7277: A YANG Data Model for IP Management"; "RFC 7277: A YANG Data Model for IP Management";
} }
/* /*
* Features * Features
*/ */
feature ipv4-non-contiguous-netmasks { feature ipv4-non-contiguous-netmasks {
description description
"Indicates support for configuring non-contiguous "Indicates support for configuring non-contiguous
subnet masks."; subnet masks.";
skipping to change at page 9, line 19 skipping to change at page 8, line 31
*/ */
feature ipv4-non-contiguous-netmasks { feature ipv4-non-contiguous-netmasks {
description description
"Indicates support for configuring non-contiguous "Indicates support for configuring non-contiguous
subnet masks."; subnet masks.";
} }
feature ipv6-privacy-autoconf { feature ipv6-privacy-autoconf {
description description
"Indicates support for Privacy Extensions for Stateless Address "Indicates support for privacy extensions for stateless address
Autoconfiguration in IPv6."; autoconfiguration in IPv6.";
reference reference
"RFC 4941: Privacy Extensions for Stateless Address "RFC 4941: Privacy Extensions for Stateless Address
Autoconfiguration in IPv6"; Autoconfiguration in IPv6";
} }
/* /*
* Typedefs * Typedefs
*/ */
typedef ip-address-origin { typedef ip-address-origin {
type enumeration { type enumeration {
enum other { enum other {
description description
"None of the following."; "None of the following.";
} }
enum static { enum static {
description description
"Indicates that the address has been statically "Indicates that the address has been statically
configured - for example, using NETCONF or a Command Line configured -- for example, using the Network Configuration
Interface."; Protocol (NETCONF) or a command line interface.";
} }
enum dhcp { enum dhcp {
description description
"Indicates an address that has been assigned to this "Indicates an address that has been assigned to this
system by a DHCP server."; system by a DHCP server.";
} }
enum link-layer { enum link-layer {
description description
"Indicates an address created by IPv6 stateless "Indicates an address created by IPv6 stateless
autoconfiguration that embeds a link-layer address in its autoconfiguration that embeds a link-layer address in its
interface identifier."; interface identifier.";
} }
enum random { enum random {
description description
"Indicates an address chosen by the system at "Indicates an address chosen by the system at
random, e.g., an IPv4 address within 169.254/16, a
random, e.g., an IPv4 address within 169.254/16, an temporary address as described in RFC 4941, or a
RFC 4941 temporary address, or an RFC 7217 semantically semantically opaque address as described in RFC 7217.";
opaque address.";
reference reference
"RFC 4941: Privacy Extensions for Stateless Address "RFC 4941: Privacy Extensions for Stateless Address
Autoconfiguration in IPv6 Autoconfiguration in IPv6
RFC 7217: A Method for Generating Semantically Opaque RFC 7217: A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Interface Identifiers with IPv6 Stateless
Address Autoconfiguration (SLAAC)"; Address Autoconfiguration (SLAAC)";
} }
} }
description description
"The origin of an address."; "The origin of an address.";
skipping to change at page 10, line 32 skipping to change at page 9, line 48
typedef neighbor-origin { typedef neighbor-origin {
type enumeration { type enumeration {
enum other { enum other {
description description
"None of the following."; "None of the following.";
} }
enum static { enum static {
description description
"Indicates that the mapping has been statically "Indicates that the mapping has been statically
configured - for example, using NETCONF or a Command Line configured -- for example, using NETCONF or a command line
Interface."; interface.";
} }
enum dynamic { enum dynamic {
description description
"Indicates that the mapping has been dynamically resolved "Indicates that the mapping has been dynamically resolved
using, e.g., IPv4 ARP or the IPv6 Neighbor Discovery using, for example, IPv4 ARP or the IPv6 Neighbor
protocol."; Discovery protocol.";
} }
} }
description description
"The origin of a neighbor entry."; "The origin of a neighbor entry.";
} }
/* /*
* Data nodes * Data nodes
*/ */
skipping to change at page 11, line 38 skipping to change at page 11, line 8
description description
"Controls IPv4 packet forwarding of datagrams received by, "Controls IPv4 packet forwarding of datagrams received by,
but not addressed to, this interface. IPv4 routers but not addressed to, this interface. IPv4 routers
forward datagrams. IPv4 hosts do not (except those forward datagrams. IPv4 hosts do not (except those
source-routed via the host)."; source-routed via the host).";
} }
leaf mtu { leaf mtu {
type uint16 { type uint16 {
range "68..max"; range "68..max";
} }
units octets; units "octets";
description description
"The size, in octets, of the largest IPv4 packet that the "The size, in octets, of the largest IPv4 packet that the
interface will send and receive. interface will send and receive.
The server may restrict the allowed values for this leaf, The server may restrict the allowed values for this leaf,
depending on the interface's type. depending on the interface's type.
If this leaf is not configured, the operationally used MTU If this leaf is not configured, the operationally used MTU
depends on the interface's type."; depends on the interface's type.";
reference reference
skipping to change at page 12, line 16 skipping to change at page 11, line 34
"The list of IPv4 addresses on the interface."; "The list of IPv4 addresses on the interface.";
leaf ip { leaf ip {
type inet:ipv4-address-no-zone; type inet:ipv4-address-no-zone;
description description
"The IPv4 address on the interface."; "The IPv4 address on the interface.";
} }
choice subnet { choice subnet {
mandatory true; mandatory true;
description description
"The subnet can be specified as a prefix-length, or, "The subnet can be specified as a prefix length or,
if the server supports non-contiguous netmasks, as if the server supports non-contiguous netmasks, as
a netmask."; a netmask.";
leaf prefix-length { leaf prefix-length {
type uint8 { type uint8 {
range "0..32"; range "0..32";
} }
description description
"The length of the subnet prefix."; "The length of the subnet prefix.";
} }
leaf netmask { leaf netmask {
skipping to change at page 14, line 10 skipping to change at page 13, line 36
forward datagrams. IPv6 hosts do not (except those forward datagrams. IPv6 hosts do not (except those
source-routed via the host)."; source-routed via the host).";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
Section 6.2.1, IsRouter"; Section 6.2.1, IsRouter";
} }
leaf mtu { leaf mtu {
type uint32 { type uint32 {
range "1280..max"; range "1280..max";
} }
units octets; units "octets";
description description
"The size, in octets, of the largest IPv6 packet that the "The size, in octets, of the largest IPv6 packet that the
interface will send and receive. interface will send and receive.
The server may restrict the allowed values for this leaf, The server may restrict the allowed values for this leaf,
depending on the interface's type. depending on the interface's type.
If this leaf is not configured, the operationally used MTU If this leaf is not configured, the operationally used MTU
depends on the interface's type."; depends on the interface's type.";
reference reference
"RFC 2460: Internet Protocol, Version 6 (IPv6) "RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification Specification
Section 5"; Section 5";
} }
list address { list address {
key "ip"; key "ip";
description description
"The list of IPv6 addresses on the interface."; "The list of IPv6 addresses on the interface.";
leaf ip { leaf ip {
type inet:ipv6-address-no-zone; type inet:ipv6-address-no-zone;
description description
"The IPv6 address on the interface."; "The IPv6 address on the interface.";
} }
skipping to change at page 19, line 37 skipping to change at page 20, line 14
/* /*
* Legacy operational state data nodes * Legacy operational state data nodes
*/ */
augment "/if:interfaces-state/if:interface" { augment "/if:interfaces-state/if:interface" {
status deprecated; status deprecated;
description description
"Data nodes for the operational state of IP on interfaces."; "Data nodes for the operational state of IP on interfaces.";
container ipv4 { container ipv4 {
presence "Present if IPv4 is enabled on this interface"; presence
"Present if IPv4 is enabled on this interface";
config false; config false;
status deprecated; status deprecated;
description description
"Interface-specific parameters for the IPv4 address family."; "Interface-specific parameters for the IPv4 address family.";
leaf forwarding { leaf forwarding {
type boolean; type boolean;
status deprecated; status deprecated;
description description
"Indicates whether IPv4 packet forwarding is enabled or "Indicates whether IPv4 packet forwarding is enabled or
disabled on this interface."; disabled on this interface.";
} }
leaf mtu { leaf mtu {
type uint16 { type uint16 {
range "68..max"; range "68..max";
} }
units octets; units "octets";
status deprecated; status deprecated;
description description
"The size, in octets, of the largest IPv4 packet that the "The size, in octets, of the largest IPv4 packet that the
interface will send and receive."; interface will send and receive.";
reference reference
"RFC 791: Internet Protocol"; "RFC 791: Internet Protocol";
} }
list address { list address {
key "ip"; key "ip";
status deprecated; status deprecated;
skipping to change at page 20, line 29 skipping to change at page 21, line 7
leaf ip { leaf ip {
type inet:ipv4-address-no-zone; type inet:ipv4-address-no-zone;
status deprecated; status deprecated;
description description
"The IPv4 address on the interface."; "The IPv4 address on the interface.";
} }
choice subnet { choice subnet {
status deprecated; status deprecated;
description description
"The subnet can be specified as a prefix-length, or, "The subnet can be specified as a prefix length or,
if the server supports non-contiguous netmasks, as if the server supports non-contiguous netmasks, as
a netmask."; a netmask.";
leaf prefix-length { leaf prefix-length {
type uint8 { type uint8 {
range "0..32"; range "0..32";
} }
status deprecated; status deprecated;
description description
"The length of the subnet prefix."; "The length of the subnet prefix.";
} }
skipping to change at page 21, line 40 skipping to change at page 22, line 20
leaf origin { leaf origin {
type neighbor-origin; type neighbor-origin;
status deprecated; status deprecated;
description description
"The origin of this neighbor entry."; "The origin of this neighbor entry.";
} }
} }
} }
container ipv6 { container ipv6 {
presence "Present if IPv6 is enabled on this interface"; presence
"Present if IPv6 is enabled on this interface";
config false; config false;
status deprecated; status deprecated;
description description
"Parameters for the IPv6 address family."; "Parameters for the IPv6 address family.";
leaf forwarding { leaf forwarding {
type boolean; type boolean;
default false; default false;
status deprecated; status deprecated;
description description
"Indicates whether IPv6 packet forwarding is enabled or "Indicates whether IPv6 packet forwarding is enabled or
disabled on this interface."; disabled on this interface.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
Section 6.2.1, IsRouter"; Section 6.2.1, IsRouter";
} }
leaf mtu { leaf mtu {
type uint32 { type uint32 {
range "1280..max"; range "1280..max";
} }
units octets; units "octets";
status deprecated; status deprecated;
description description
"The size, in octets, of the largest IPv6 packet that the "The size, in octets, of the largest IPv6 packet that the
interface will send and receive."; interface will send and receive.";
reference reference
"RFC 2460: Internet Protocol, Version 6 (IPv6) "RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification Specification
Section 5"; Section 5";
} }
list address { list address {
key "ip"; key "ip";
status deprecated; status deprecated;
description description
"The list of IPv6 addresses on the interface."; "The list of IPv6 addresses on the interface.";
leaf ip { leaf ip {
skipping to change at page 25, line 48 skipping to change at page 26, line 38
"The Neighbor Unreachability Detection state of this "The Neighbor Unreachability Detection state of this
entry."; entry.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
Section 7.3.2"; Section 7.3.2";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5. IANA Considerations 5. IANA Considerations
This document registers a URI in the "IETF XML Registry" [RFC3688]. This document registers a URI in the "IETF XML Registry" [RFC3688].
Following the format in RFC 3688, the following registration has been Following the format in RFC 3688, the following registration has been
made. made.
URI: urn:ietf:params:xml:ns:yang:ietf-ip URI: urn:ietf:params:xml:ns:yang:ietf-ip
Registrant Contact: The NETMOD WG of the IETF.
Registrant Contact: The NETMOD WG of the IETF. XML: N/A; the requested URI is an XML namespace.
XML: N/A; the requested URI is an XML namespace.
This document registers a YANG module in the "YANG Module Names" This document registers a YANG module in the "YANG Module Names"
registry [RFC6020]. registry [RFC6020].
Name: ietf-ip Name: ietf-ip
Namespace: urn:ietf:params:xml:ns:yang:ietf-ip Namespace: urn:ietf:params:xml:ns:yang:ietf-ip
Prefix: ip Prefix: ip
Reference: RFC 7277 Reference: RFC 8344
6. Security Considerations 6. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246]. [RFC5246].
The NETCONF access control model [RFC6536] provides the means to The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. operations and content.
There are a number of data nodes defined in the YANG module which are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
ipv4/enabled and ipv6/enabled: These leafs are used to enable or ipv4/enabled and ipv6/enabled: These leafs are used to enable or
disable IPv4 and IPv6 on a specific interface. By enabling a disable IPv4 and IPv6 on a specific interface. By enabling a
protocol on an interface, an attacker might be able to create an protocol on an interface, an attacker might be able to create an
skipping to change at page 27, line 28 skipping to change at page 28, line 28
able to deny service to users. By enabling the forwarding able to deny service to users. By enabling the forwarding
functions, an attacker could open a conduit into an area. This functions, an attacker could open a conduit into an area. This
might result in the area providing transit for packets it might result in the area providing transit for packets it
shouldn't, or it might allow the attacker access to the area, shouldn't, or it might allow the attacker access to the area,
bypassing security safeguards. bypassing security safeguards.
ipv6/autoconf: The leafs in this branch control the ipv6/autoconf: The leafs in this branch control the
autoconfiguration of IPv6 addresses and, in particular, whether or autoconfiguration of IPv6 addresses and, in particular, whether or
not temporary addresses are used. By modifying the corresponding not temporary addresses are used. By modifying the corresponding
leafs, an attacker might impact the addresses used by a node and leafs, an attacker might impact the addresses used by a node and
thus indirectly the privacy of the users using the node. -- thus, indirectly -- the privacy of the users using the node.
ipv4/mtu and ipv6/mtu: Setting these leafs to very small values can ipv4/mtu and ipv6/mtu: Setting these leafs to very small values can
be used to slow down interfaces. be used to slow down interfaces.
7. Acknowledgments 7. References
The author wishes to thank Jeffrey Lange, Ladislav Lhotka, Juergen
Schoenwaelder, and Dave Thaler for their helpful comments.
8. References
8.1. Normative References
[I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore
Architecture", draft-ietf-netmod-revised-datastores-07
(work in progress), November 2017.
[I-D.ietf-netmod-rfc7223bis] 7.1. Normative References
Bjorklund, M., "A YANG Data Model for Interface
Management", draft-ietf-netmod-rfc7223bis-01 (work in
progress), December 2017.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, <https://www.rfc- DOI 10.17487/RFC0791, September 1981,
editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004,
editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, <https://www.rfc- DOI 10.17487/RFC4861, September 2007,
editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, <https://www.rfc- DOI 10.17487/RFC4862, September 2007,
editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc- DOI 10.17487/RFC5246, August 2008,
editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, <https://www.rfc- DOI 10.17487/RFC6020, October 2010,
editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
skipping to change at page 29, line 21 skipping to change at page 30, line 21
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, RFC 2119 Key Words", BCP 14, RFC 8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References [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>.
[I-D.ietf-netmod-yang-tree-diagrams] [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Access Control Model", STD 91, RFC 8341,
ietf-netmod-yang-tree-diagrams-02 (work in progress), DOI 10.17487/RFC8341, March 2018,
October 2017. <https://www.rfc-editor.org/info/rfc8341>.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [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
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982, RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>. <https://www.rfc-editor.org/info/rfc826>.
[RFC4293] Routhier, S., Ed., "Management Information Base for the [RFC4293] Routhier, S., Ed., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293,
April 2006, <https://www.rfc-editor.org/info/rfc4293>. April 2006, <https://www.rfc-editor.org/info/rfc4293>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
editor.org/info/rfc6536>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, <https://www.rfc- DOI 10.17487/RFC7217, April 2014,
editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", RFC 8022, DOI 10.17487/RFC8022, November Management", RFC 8022, DOI 10.17487/RFC8022,
2016, <https://www.rfc-editor.org/info/rfc8022>. November 2016, <https://www.rfc-editor.org/info/rfc8022>.
Appendix A. Example: NETCONF <get-config> reply [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
This section gives an example of a reply to the NETCONF <get-config> This section gives an example of a reply to the NETCONF <get-config>
request for the running configuration datastore for a device that request for the running configuration datastore for a device that
implements the data model defined in this document. 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.
<rpc-reply <rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101"> message-id="101">
<data> <data>
<interfaces <interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"> xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<type>ianaift:ethernetCsmacd</type> <type>ianaift:ethernetCsmacd</type>
skipping to change at page 30, line 51 skipping to change at page 33, line 12
</data> </data>
</rpc-reply> </rpc-reply>
Appendix B. Example: NETCONF <get-data> Reply Appendix B. Example: NETCONF <get-data> Reply
This section gives an example of a reply to the NETCONF <get-data> This section gives an example of a reply to the NETCONF <get-data>
request for the operational state datastore for a device that request for the operational state datastore for a device that
implements the data model defined in this document. implements the data model defined in this document.
This example uses the "origin" annotation, which is defined in the This example uses the "origin" annotation, which is defined in the
module "ietf-origin" [I-D.ietf-netmod-revised-datastores]. module "ietf-origin" [RFC8342].
<rpc-reply <rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101"> message-id="101">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores"> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores">
<interfaces <interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
skipping to change at page 32, line 19 skipping to change at page 34, line 33
<is-router/> <is-router/>
<state>reachable</state> <state>reachable</state>
</neighbor> </neighbor>
<neighbor or:origin="or:learned"> <neighbor or:origin="or:learned">
<ip>2001:db8::4</ip> <ip>2001:db8::4</ip>
<origin>dynamic</origin> <origin>dynamic</origin>
<state>incomplete</state> <state>incomplete</state>
</neighbor> </neighbor>
</ipv6> </ipv6>
</interface> </interface>
</interfaces> </interfaces>
</data> </data>
</rpc-reply> </rpc-reply>
Acknowledgments
The author wishes to thank Jeffrey Lange, Ladislav Lhotka, Juergen
Schoenwaelder, and Dave Thaler for their helpful comments.
Author's Address Author's Address
Martin Bjorklund Martin Bjorklund
Tail-f Systems Tail-f Systems
Email: mbj@tail-f.com Email: mbj@tail-f.com
 End of changes. 71 change blocks. 
167 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/