Yang Data Model for IPIPv4 Tunnel

An overview of tunnel is presented at [intarea-tunnel]. Over the past several years, there has been a number of "tunneling" protocols specified by the IETF. And this document defines a YANG data model for the management of IP bases tunnels. In default format, it covers the following tunnel types: o IPv4 in IPv4, related concepts are defined in [RFC1853] o IPv6 in IPv4 manual tunnel, related concepts are defined in [RFC2003] o IPv6 to IPv4 tunnel, related concepts are defined in [RFC3056] And notice that this model provides a framework and some reusable common attributes where technology-specific IP tunnel YANG models can inherit constructs from it without needing to redefine them within the sub-technology. Therefore it also can serve as a base model which can be extended to include technology specific details.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration (read-write), and "ro" means state data (read-only). o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown.

In this document we define an IP based tunnel model, in default it can describe the IPv6/4-in-IPv4 tunnels including IPv4 in IPv4 [RFC1853], IPv6 in IPv4 [RFC2003], IPv6 to IPv4 [RFC3056]. Since some reusable common core attributes of ip tunnels are defined, it can also provide an optional solution for extending to the other IP-based tunnel models. The users of IP-based tunnel model can according to following method to define other technologies specific ip tunnel models: o The IP based Tunnel YANG model can acts as the root for other Tunnel YANG models. o Augment the ip based tunnel model by adding the tunnel type is defined as an identity that augments the base " ip-tunnel-type " defined in the IP based model. o Augment the ip based tunnel model by adding new data nodes with technology specific parameters into proper anchor points of the ip tunnel model. Figure 1 depicts the relationship of different Tunnel YANG models to the Ip Tunnel YANG Model. It can default support the IPv4-in-IPv4, IPv6-in-IPv4, and IPv6-to-IPv4, and can also be extended to another IP base tunnels encapsulation protocol.

+--------------------------+ | | | IP BASED TUNNEL YANG | | | +-------------+------------+ | | +------------+-------+---------+---------------+ | | | | augment +--------------------------------------------+ | | +-------+ +----+-------+ +---------+ | +--+--------+ | | IPv4 | |IPv6 in IPv4| |IPv6 to IPv4 | | another | | |in IPv4| | yang | | tunnel | | | IP tunnels| | | yang | | | | yang | | | yang | | +-------+ +------------+ +---------+ | +-----------+ | default support | | | +--------------------------------------------+

This document defines the YANG model "ietf-ip-tunnel". It includes two modules, one for configuration and one for state. At the top of the Model there is Tunnels container for tunnel configuration data. Multiple Tunnel lists keyed using tunnel name and tunnel type within the Tunnels container. To correctly identify an ip based tunnel the bind-interface, local-address, remote-address are defined under one tunnel list. Notice that tunnels are handled by creating a logical interface for each tunnel. Each logical interface (physical or virtual) need to map to interface yang model [RFC7223]. To do so, in this draft, the bind-interface are defined which with a leafref type and it can be used pointing to the corresponding interface-name node in the interface yang [RFC7223]. The data model also includes read-only counter so that the tunnel state can be read.

The data model has the following tree diagram for the IP tunnels:

module: ietf-ip-tunnel +--rw Tunnels | +--rw Tunnel* [name type] | +--rw name string | +--rw type identityref | +--rw local-address? inet:ip-address-no-zone | +--rw remote-address? inet:ip-address-no-zone | +--rw routing-instance? routing-instance-ref | +--rw description? string | +--rw bind-interface? if:interface-ref | +--rw clear-df? empty | +--rw shutdown? empty | +--rw tmtu? uint16 | +--rw mirror-destination? string | +--rw hop-limit? uint8 | +--rw tos? int8 +--ro tunnel-state +--ro tunnels* +--ro name? string +--ro type? identityref +--ro local-ip? inet:ip-address-no-zone +--ro remote-ip? inet:ip-address-no-zone +--ro (state)? | +--:(up) | | +--ro up? empty | +--:(down) | | +--ro down? empty | +--:(shutdown) | +--ro shutdown? empty +--ro bind-interface? if:interface-state-ref +--ro user-configured? boolean +--ro routing-instance? routing-instance-ref +--ro tmtu? uint16 +--ro clear-df? empty +--ro down-reason? string +--ro resolved-interface-name? string +--ro hop-limit? uint32 +--ro tos? int32 augment /if:interfaces-state/if:interface: +--ro tunnel-protocol? identityref

<CODE BEGINS> file "ietf-ip-tunnel@2016-06-20.yang" module ietf-ip-tunnel{ namespace "urn:ietf:params:xml:ns:yang:ietf-ip-tunnel"; prefix "iptnl"; import ietf-interfaces { prefix "if"; } import ietf-inet-types { prefix inet; } import ietf-routing { prefix "rt"; } import iana-if-type { prefix ianaift; } organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group."; contact "Mandy.Liu@ericsson.com Adam.Foldes@ericsson.com zhengguangying@huawei.com"; description "This YANG model defines the configuration data and operational state data for generic IPv4/6-in-IPv4 tunnel. It includes the IPv4 in IPv4, 6-to-4, and IPv6 over IPv4 manual tunnels."; revision 2016-04-27 { description "Made model more generic in order to allow augmentation by e.g. GRE tunnels."; reference "RFC XXXX: A YANG Data Model for IPv4 Tunnel."; } revision 2016-03-11 { description "Collapsed all tunnel types into a single subtree based on suggestions to more closely follow the IP Tunnel MIB."; reference "RFC XXXX: A YANG Data Model for IPv4 Tunnel."; } revision 2015-10-14 { description "Update model based on comments."; reference "RFC XXXX: A YANG Data Model for IPv4 Tunnel."; } revision 2015-07-20 { description "This version adds the following new items: - hop-limit - tos - tunnel-type This version changes 'ipv6to4-auto' to 'ipv6to4'"; reference "RFC XXXX: A YANG Data Model for IPv4 Tunnel."; } revision 2015-05-27 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for IPv4 Tunnel."; } /* Identities */ identity ip-tunnel-type { description "Base identity from which identities describing IP tunnel types are derived."; } identity ip-ip { base ip-tunnel-type; description "This identity represents IPv4-in-IPv4 tunnel type"; } identity ipv6v4-manual { base ip-tunnel-type; description "This identity represents IPv6-to-IPv4 manual tunnel type"; } identity ipv6-to-v4 { base ip-tunnel-type; description "This identity represents the 6-to-4 tunnel type"; } typedef routing-instance-ref { type leafref { path "/rt:routing/rt:routing-protocols/rt:routing-protocol/rt:name"; } description "This type is used for leafs that reference a routing instance configuration."; } /*Configuration Data*/ container Tunnels{ description "Configuration data for tunnels."; list Tunnel{ key "name type"; description "Configuration data for tunnels."; leaf name { type string; description "Name of the tunnel."; } leaf type { type identityref { base ip-tunnel-type; } description "The encapsulation type of the tunnel."; } leaf routing-instance { type routing-instance-ref; description "The routing instance of the local address."; } uses tunnel-config-components; } } /* Configuration data */ grouping tunnel-config-components { description "Configuration data for all tunnels and subtunnels"; leaf description { type string { length "1..255"; } description "Textual description for a tunnel. Can be any "+ "alphanumeric string, including spaces, not to exceed "+ "255 ASCII characters."; } leaf bind-interface { type if:interface-ref; description "Bind to an interface."; } leaf local-address { type inet:ip-address-no-zone; description "IP address of the local end of the tunnel."; } leaf remote-address { when "type != ipv6-to-v4" { description "6-to-4 tunnels do not have a fixed remote endpoint."; } type inet:ip-address-no-zone; description "IP address of the remote end of the tunnel."; } leaf clear-df { type empty; description "If clear-df is absent, it means that fragmentation of tunnel packets are permitted. If clear-df is present, it means that fragmentation of tunnel packets are not permitted."; } leaf shutdown { type empty; description "Disable/enable the tunnel."; } leaf tmtu { type uint16 { range "256..16384"; } description "Sets the Maximum Transmission Unit (MTU) size for packets sent in a tunnel. The default MTU is the MTU for the interface to which the tunnel is bound."; } leaf mirror-destination { type string; description "Designate the name of a tunnel as a circuit mirror destination. "; } leaf hop-limit { type uint8 { range "0|1..255"; } description "The IPv4 TTL or IPv6 Hop Limit which is used in the outer IP header. A value of 0 indicates that the value is copied from the payload's header."; } leaf tos { type int8 { range "-1..63"; } description "The method used to set the high 6 bits (the differentiated services codepoint) of the IPv4 TOS or IPv6 Traffic Class in the outer IP header. A value of -1 indicates that the bits are copied from the payload\u2019s header. A value between 0 and 63 inclusive indicates that the bit field is set to the indicated value."; } } /*Operational state data*/ grouping tunnel-oper-states { description "Operational states of tunnels"; choice state { description "Choice of operational states"; case up { leaf up { type empty; description "The tunnel is up."; } } case down { leaf down { type empty; description "The tunnel is down."; } } case shutdown { leaf shutdown { type empty; description "The tunnel is shut down administratively."; } } } } grouping tunnel-state-components { description "The basic tunnel information to be displayed."; leaf name { type string; description "Name of the tunnel."; } leaf type { type identityref; description "The type of the tunnel."; } leaf local-ip { type inet:ip-address-no-zone; description "IP address of the local end of the tunnel."; } leaf remote-ip { type inet:ip-address-no-zone; description "IP address of the remote end of the tunnel."; } uses tunnel-oper-states; leaf bind-interface { type if:interface-state-ref; description "Bind to an interface."; } leaf user-configured { type boolean; description "Indicate the tunnel is user-configured or dynamic. False is for dynamic."; } leaf routing-instance { type routing-instance-ref; description "Name of the reference routing instance. "; } leaf tmtu { type uint16; description "The Maximum Transmission Unit (MTU) size for packets sent in a tunnel."; } leaf clear-df { type empty; description "Indicate that the DF bit is cleared."; } leaf down-reason { type string; description "The reason of the tunnel is down."; } leaf resolved-interface-name{ type string; description "The egress interface name of the tunnel."; } leaf hop-limit { type uint32; description "The IPv4 TTL or IPv6 Hop Limit which is used in the outer IP header. A value of 0 indicates that the calue is copied from the payload's header."; } leaf tos { type int32; description "The high 6 bits (the differentiated services codepoint) of the IPv4 TOS or IPv6 Traffic Class in the outer IP header. A value of -1 indicates that the bits are copied from the payload\u2019s header. A value between 0 and 63 inclusive indicates that the bit field is set to the indicated value."; } } container tunnel-state { config "false"; description "Contain the information currently configured tunnels."; list tunnels { description "Operational state data of tunnels."; uses tunnel-state-components; } } //Augment operational state data of IP interfaces augment "/if:interfaces-state/if:interface" { when "if:type = 'ianaift:tunnel'" { description "Augment IP interface."; } description "Augment operational state data of IP interfaces."; leaf tunnel-protocol { type identityref; description "Indicate the state of the IP tunnel interface."; } } } <CODE ENDS>

The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241] . The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242] . The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content.

This document registers a URI in the IETF XML registry [RFC3688] . Following the format in RFC 3688, the following registration is requested to be made:

URI: urn:ietf:params:xml:ns:yang:ietf-ip-tunnel Registrant Contact: The IESG. 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-tunnel namespace:urn:ietf:params:xml:ns:yang:ietf-ip-tunnel prefix: itun reference: RFC XXXX