One document matched: draft-ietf-l2tpext-keyed-v6-tunnel-yang-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3931 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3931.xml">
<!ENTITY rfc6020 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY rfc6241 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY rfc6991 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6991.xml">
<!ENTITY rfc6242 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY rfc6536 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6536.xml">
<!ENTITY rfc7223 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7223.xml">
]>
<rfc category="std" docName="draft-ietf-l2tpext-keyed-v6-tunnel-yang-02" ipr="trust200902">
<front>
<title abbrev="Keyed IPv6 Tunnel YANG">A YANG Data Model for Keyed IPv6 Tunnels</title>
<author fullname="Qi Sun" initials="Q." surname="Sun">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>CTO-ATI,Landgrabenweg 151</street>
<city>Bonn</city>
<region>NRW</region>
<code>53227</code>
<country>Germany</country>
</postal>
<email>qui.sun@external.telekom.de</email>
</address>
</author>
<author fullname="Ian Farrer" initials="I." surname="Farrer">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>CTO-ATI,Landgrabenweg 151</street>
<city>Bonn</city>
<region>NRW</region>
<code>53227</code>
<country>Germany</country>
</postal>
<email>ian.farrer@telekom.de</email>
</address>
</author>
<author fullname="Bing Liu" initials="B." surname="Liu">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street>
<city>Beijing</city>
<region>Hai-Dian District</region>
<code>100095</code>
<country>P.R. China</country>
</postal>
<email>leo.liubing@huawei.com</email>
</address>
</author>
<author fullname="Giles Heron" initials="G." surname="Heron">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>9-11 New Square, Bedfont Lakes</street>
<city>Feltham</city>
<region>Middlesex</region>
<code>TW14 8HA</code>
<country>United Kingdom</country>
</postal>
<email>giheron@cisco.com</email>
</address>
</author>
<date day="28" month="October" year="2016"/>
<workgroup>l2tpext Working Group</workgroup>
<abstract>
<t>This document defines a YANG data model for the configuration and
management of Keyed IPv6 tunnels. The data model includes both
configuration and state data. Due to the stateless nature of
keyed IPv6 tunnels, a model for NETCONF notifications is not necessary.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</note>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t><xref target="I-D.ietf-l2tpext-keyed-ipv6-tunnel">Keyed IPv6 Tunnels</xref>
defines a mechanism for transporting L2 Ethernet frames over IPv6 using L2TPv3
tunnel encapsulation with a mandatory 64-bit cookie. It is a static layer 2
tunnelling mechanism that leverages IPv6's vast number of IP addresses to uniquely
identify each tunnel, instead of using the L2TPv3 Session ID as the differentiator
(as defined in <xref target="RFC3931"/>). The layer 2 circuit is mapped to
an IPv6 address on the network side so typically, there is one session
per-tunnel.</t>
<t>Since the L2TPv3 control plane is not used by Keyed IPv6 tunnels, the
parameters for building a Keyed IPv6 tunnel need to be pre-configured on the
two tunnel endpoint devices.
<xref target="RFC6241">NETCONF</xref>/<xref target="RFC6020">YANG</xref>
provide mechanisms for such configuration. This document defines a YANG
data model for the configuration and management of Keyed IPv6 Tunnels.
</t>
<section anchor="terminology" title="Terminology">
<section title="Requirements Notations">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="NETCONF Terms">
<t>The following terms are defined in <xref target="RFC6241"/> and
are not redefined here:</t>
<t>
<list style="symbols">
<t>Client</t>
<t>Server</t>
<t>Operation</t>
</list>
</t>
</section>
<section title="YANG Terms">
<t>The following terms are defined in <xref target="RFC6020"/> and
are not redefined here:</t>
<t>
<list style="symbols">
<t>configuration data</t>
<t>data node</t>
<t>data tree</t>
<t>module</t>
<t>namespace</t>
<t>YANG</t>
</list>
</t>
</section>
<section title="Tree Diagrams">
<t>A simplified graphical representation of the data model is provided
in this document. The meaning of the symbols in these diagrams is as
follows:</t>
<t>
<list style="symbols">
<t>Brackets "[" and "]" enclose list keys.</t>
<t>Abbreviations before data node names: "rw" means configuration
data (read-write), and "ro" means state data (read-only).</t>
<t>Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.</t>
<t>Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").</t>
<t>Ellipsis ("...") stands for the contents of subtrees that are not
shown.</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="overview" title="YANG Model Overview">
<t>The YANG model comprises of two modules, one for configuration and one for
state. To correctly identify a tunnel and create the mapping between the
L2 circuit and the IPv6 address, the tuple of source interface, local IPv6
address and remote IPv6 address MUST be unique. Because Session ID is not
mandatory for a Keyed IPv6 tunnel to function, Session ID related parameters
are optional in the model. Cookies MUST be 64-bit long according to
Section 3 of <xref target="I-D.ietf-l2tpext-keyed-ipv6-tunnel"></xref>.
The requirement for 64-bit cookie constrains interoperability with
existing RFC3931 implementations to those configured with a 64-bit cookie.</t>
<t>The data model also includes read-only counters so that statistics for
sent and received octets and packets, received packets with errors, and
packets that could not be sent due to errors can be read.</t>
<t>This model defines three features for OAM parameters. Those
features enable devices to perform related OAM operations on the tunnel
if related functions are supported. </t>
</section>
<section anchor="tree-diagram" title="Keyed IPv6 Tunnel YANG Tree Diagrams">
<t>This section describes the tree diagram for the Keyed IPv6 Tunnel YANG
model:</t>
<figure align="center" anchor="k6tun-tree" title="Keyed IPv6 Tunnel Tree">
<artwork><![CDATA[
module: ietf-keyed-v6-tunnel
+--rw tunnelConfigurations
| +--rw tunnelConfiguration* [tunnelName]
| | +--rw tunnelName string
| | +--rw srcInterface if:interface-ref
| | +--rw localIPv6 inet:ipv6-address
| | +--rw remoteIPv6 inet:ipv6-address
| | +--rw localSessionId? uint32
| | +--rw remoteSessionId? uint32
| | +--rw localCookies
| | | +--rw localCookie* [cookieName]
| | | +--rw cookieName string
| | | +--rw cookieValue uint64
| | +--rw remoteCookie uint64
| | +--rw retainFCS? empty
| | +--rw enable-vccv!
| | | +--rw enable-bfd? empty
| | +--rw enable-bfd? empty
| +--rw disable-pmtu? empty
| +--rw enable-fragmentation!
| | +--rw fragment-mru? uint16
| +--rw enable-sequencing empty
+--ro tunnelStates
+--ro tunnelState* [tunnelName]
+--ro tunnelName string
+--ro sentPacket? yang:zero-based-counter64
+--ro sentByte? yang:zero-based-counter64
+--ro rcvdPacket? yang:zero-based-counter64
+--ro rcvdByte? yang:zero-based-counter64
+--ro droppedPacket? yang:zero-based-counter64
+--ro droppedByte? yang:zero-based-counter64
+--ro fragmentCounter? yang:zero-based-counter64
]]></artwork>
</figure>
<t>The data model defines a configuration container and a state container.</t>
<t>In the configuration container, "srcInterface" is used to identify a L2
circuit endpoint. "localIPv6" and "remoteIPv6" respectively hold the local
(source) and remote (destination) IPv6 addresses for the tunnel. The tuple of
srcInterface and localIPv6 uniquely identify a tunnel endpoint. If a virtual
interface is used, the tuple of localIPv6 and remoteIPv6 MUST also be unique.
"localCookie" is a list containing two cookies: one is the newly configured
cookie, and the other is previously configured. This is used for the purpose of
correctly receiving packets while changing cookies.</t>
<t>Nodes are defined for FCS-Retention, VCCV, BFD, VCCV-BFD and fragmentation,
so that devices supporting all or some of these features can be configured.</t>
</section>
<section anchor="k6tun-model" title="Keyed IPv6 Tunnel YANG Model">
<t>This module imports typedefs from <xref target="RFC6991"></xref> and
<xref target="RFC7223"/>.</t>
<figure>
<artwork><![CDATA[
<CODE BEGINS> file "ietf-keyed-v6-tunnel@2016-03-21.yang"
module ietf-keyed-v6-tunnel {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-keyed-v6-tunnel";
prefix k6tun;
import ietf-interfaces {
prefix if;
}
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix yang;
}
organization "IETF l2tpext Working Group";
contact
"qui.sun@external.telekom.de
ian.farrer@telekom.de
leo.liubing@huawei.com
giheron@cisco.com
";
description
"Keyed IPv6 L2TPv3 Tunnel";
revision 2016-03-21 {
description
"Added sequencing feature";
reference
"draft-ietf-l2tpext-keyed-v6-tunnel-yang-01";
}
revision 2015-07-06 {
description
"General clean-up"
;
reference
"draft-sun-l2tpext-keyed-v6-tunnel-yang-01";
}
revision 2015-03-09 {
description
"Initial version.
";
reference
"draft-sun-l2tpext-keyed-v6-tunnel-yang-00";
}
/*
* features
*/
feature FCS-Retention {
description
"Device supports the retention of frame check sequence (FCS)
as per Section 4.7 of RFC4720";
}
feature VCCV {
description
"Device supports the Pseudowire Virtual Circuit Connectivity
Verification (VCCV) as per RFC5085";
}
feature BFD {
description
"Device supports BFD over the tunnel as per RFC5883";
}
feature VCCV-BFD {
description
"Device supports BFD over VCCV as per RFC5885";
}
feature l2tpv3-fragmentation {
description
"Device supports L2TPv3 fragmentation as per RFC4623";
}
feature l2tpv3-sequencing {
description
"Device supports frame sequencing as per section 4.6.1 of
RFC3931";
}
/*
* typedefs
*/
/*
* groupings
*/
/*
* config parameters
*/
container tunnelConfigurations {
list tunnelConfiguration {
key "tunnelName";
unique "srcInterface remoteIPv6";
unique "localIPv6 remoteIPv6";
leaf tunnelName {
type string;
description "name for this keyed tunnel";
}
leaf srcInterface {
type if:interface-ref;
mandatory true;
description
"Source interface that identifies the L2 circuit
endpoint.";
}
leaf localIPv6 {
type inet:ipv6-address;
mandatory true;
description "IPv6 address for local end of keyed tunnel";
}
leaf remoteIPv6 {
type inet:ipv6-address;
mandatory true;
description "IPv6 address for remote end of keyed tunnel";
}
leaf localSessionId {
type uint32;
default 0xFFFFFFFF;
description
"As the IPv6 address is used to determine the tunnel
and there is a single session per tunnel, the Session ID
can be ignored upon receipt. For compatibility with
other tunnel termination platforms supporting two-stage
resolution (IPv6 address + Session ID), the Session ID
is configured with a random value other than all zeros.
If both ends support one-stage (IPv6 address), then
the Session ID is recommended to be set to all ones.";
}
leaf remoteSessionId {
type uint32;
default 0xFFFFFFFF;
description
"Since IPv6 address is used to determine the tunnel
and there is one session per tunnel, the Session ID
can be ignored upon receipt. For compatibility with
other tunnel termination platforms supporting two-stage
resolution (IPv6 address + Session ID) the Session ID
is configured with a random value other than all zeros.
If both ends support one-stage (IPv6 address), then
the Session ID is recommended to be set to all ones.";
}
container localCookies {
list localCookie {
key "cookieName";
leaf cookieName {
type string;
description "name identifying this cookie";
}
min-elements 2;
max-elements 2;
leaf cookieValue {
type uint64;
mandatory true;
description "value of this cookie";
}
description
"List of local cookies - must contain two entries at
all times to enable lossless cookie rollover";
}
description
"The length of cookie MUST be 64-bit. It MUST be
possible to change the cookie value at any time
in a manner that does not drop any legitimate
tunneled packets - i.e. the receiver
must accept a received cookie matching either
value during a change of cookie value.";
}
leaf remoteCookie {
type uint64;
mandatory true;
description
"The length of cookie MUST be 64-bit. A single
remote cookie is used for sending packets.";
}
leaf retainFCS {
if-feature FCS-Retention;
type empty;
description
"If this parameter is present, the router is configued
to retain FCS. Any such router MUST retain the FCS
for all frames sent over that tunnel.
";
}
container enable-vccv {
if-feature VCCV;
presence "Enable VCCV [RFC5085]";
leaf enable-bfd {
if-feature VCCV-BFD;
type empty;
description "Enable VCCV-BFD [RFC5885].";
}
description "Enable VCCV [RFC5085]";
}
leaf enable-bfd {
if-feature BFD;
type empty;
description
"Enable BFD over the tunnel [RFC5883].";
}
leaf disable-pmtu {
type empty;
description "Disable IPv6 PMTU discovery [RFC1981]";
}
container enable-fragmentation {
if-feature l2tpv3-fragmentation;
presence "Enable L2TPv3 fragmentation [RFC4623]";
leaf fragment-mru {
type uint16;
description "Explicit override for fragmentation MRU";
}
description
"Default is to fragment to PMTU (or 1500 if PMTU is
disabled) minus 52 octets for the encapsulation
overhead";
}
leaf enable-sequencing {
if-feature l2tpv3-sequencing;
type empty;
description
"Enable L2TPv3 sequencing [RFC3931 section 4.6.1]";
}
description
"keyed-v6-tunnel typically supports one l2tpv3 session
per tunnel. The srcInterface and localIPv6 both uniquely
identify a tunnel endpoint. If a virtual interface
is used, the localIPv6 and remoteIPv6 as a pair MUST
also be unique.
";
}
description
"container for list of keyed-v6-tunnel entries";
}
container tunnelStates {
config false;
list tunnelState {
key "tunnelName";
leaf tunnelName {
type string;
description "name of this keyed tunnel";
}
leaf sentPacket {
type yang:zero-based-counter64;
description
"counter for the number of packets sent over tunnel";
}
leaf sentByte {
type yang:zero-based-counter64;
description
"counter for total sent bytes (of inner packets)";
}
leaf rcvdPacket {
type yang:zero-based-counter64;
description
"counter for number of valid packets received from
tunnel";
}
leaf rcvdByte {
type yang:zero-based-counter64;
description
"counter for total received bytes (of inner packets)";
}
leaf droppedPacket {
type yang:zero-based-counter64;
description
"Counter for number of dropped packets matching this
tunnel (e.g. due to invalid received cookie,
insufficient resources to process).";
}
leaf droppedByte {
type yang:zero-based-counter64;
description
"Counter for total dropped bytes (of inner packets)";
}
leaf fragmentCounter {
type yang:zero-based-counter64;
description
"Counter for number of received fragments";
}
description "per-tunnel statistics";
}
description "container for list of tunnel statistics";
}
}
<CODE ENDS>
]]></artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations">
<t>The YANG module defined in this memo is designed to be accessed via the
NETCONF protocol <xref target="RFC6241"/>. The lowest NETCONF layer is the
secure transport layer and the mandatory to implement secure transport is
SSH <xref target="RFC6242"/>. The NETCONF access control model
<xref target="RFC6536"/> provides the means to restrict access for particular
NETCONF users to a pre-configured subset of all available NETCONF protocol
operations and content.</t>
<t>There are a number of data nodes defined in this 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:</t>
<t>/tunnelConfigurations/tunnelConfiguration: Could allow traffic to be
redirected, (man-in-the-middle attack) or mis-configured (denial-of-service
attack).</t>
<t>Some of the readable data nodes in this YANG module may be considered sensitive
or vulnerable in some network environments. It is thus important to control
read access (e.g. via get, get-config or notification) to these data nodes.
These are the subtrees and data nodes and their sensitivity/vulnerability:</t>
<t>/tunnelConfigurations/tunnelConfiguration: Could allow an attacker to
inject spoofed traffic into the network.</t>
<t>/tunnelStates/tunnelState: Could allow an attacker to get unauthorized access
to tunnel usage information.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document registers the following YANG modules in the "YANG
Module Names" registry <xref target="RFC6020"/>.</t>
<?rfc subcompact="yes"?>
<t><list style="hanging" hangIndent="16">
<t hangText="name:">ietf-keyed-v6-tunnel</t>
<t hangText="namespace:">urn:ietf:params:xml:ns:yang:ietf-keyed-v6-tunnel</t>
<t hangText="prefix:">k6tun</t>
<t hangText="reference:">TBD</t>
</list></t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Haoxing Shen for his valuable comments. </t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc6020;
&rfc6241;
&rfc6991;
&rfc6536;
&rfc6242;
&rfc7223;
<?rfc include="reference.I-D.ietf-l2tpext-keyed-ipv6-tunnel" ?>
</references>
<references title="Informative References">
&rfc3931;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 06:52:22 |