A YANG Data Model for Tunnel Interface TypesOrangeRennes35000Francemohamed.boucadair@orange.comDeutsche Telekom AGCTO-ATI, Landgrabenweg 151BonnNRW53227Germanyian.farrer@telekom.deCisco Systems, Inc.7025 Kit Creek Rd.RTPNC27709United States of AmericaRajiva@cisco.comSoftwire Working GroupsoftwireAugment tunneltunnel managementtunnel provisioningtunnel activationtunnel automationThis document specifies the initial version of a YANG module
"iana-tunnel-type", which
contains a collection of IANA-maintained YANG identities used as
interface types for tunnel interfaces. The module reflects the
"tunnelType" registry maintained by IANA. The latest revision of this
YANG module can be obtained from the IANA website.Tunnel type values are not directly added to the Tunnel Interface
Types YANG module; they must instead be added to the "tunnelType" IANA
registry. Once a new tunnel type registration is made by IANA for a new
tunneling scheme or even an existing one that is not already listed in
the current registry (e.g., LISP, NSH), IANA will update the Tunnel
Interface Types YANG module accordingly.Some of the IETF-defined tunneling techniques are not listed in the
current IANA registry. It is not the intent of this document to update
the existing IANA registry with a comprehensive list of tunnel
technologies. Registrants must follow the IETF registration procedure
for interface types whenever a new tunnel type is needed.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. IANA Tunnel Type YANG Module
. Security Considerations
. IANA Considerations
. YANG Module
. Updates to the IANA tunnelType Table
. References
. Normative References
. Informative References
. Example Usage
Acknowledgements
Authors' Addresses
IntroductionThis document specifies the initial version of the iana-tunnel-type
YANG module containing a collection of IANA-maintained YANG identities
identifying tunnel interface types. The module reflects IANA's
tunnelType registry under the SMI Numbers registry . The
latest revision of this module can be obtained from the IANA website.Tunnel-specific extensions may be added to the Interface module as a function of the tunnel type. An example of
this is provided in . It is not the
intention of this document to define tunnel-specific extensions for
every tunnel encapsulation technology; those are discussed in dedicated
documents such as .
Likewise, it is out of the scope of this document to update the existing
IANA tunnelType registry with a
comprehensive list of tunnel technologies. Guidelines and registration
procedures for interface types and sub-types are discussed in .This document uses the common YANG types defined in and adopts the Network Management Datastore
Architecture (NMDA ).The terminology for describing YANG modules is defined in . The meanings of the symbols used in the tree
diagram are defined in .IANA Tunnel Type YANG ModuleThe iana-tunnel-type module imports the 'iana-if-type' module defined
in .The initial version of the module includes tunnel types defined in
, , , and .
module iana-tunnel-type {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-tunnel-type";
prefix iana-tunnel-type;
import iana-if-type {
prefix ift;
reference
"RFC 7224: IANA Interface Type YANG Module";
}
organization
"IANA";
contact
"Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Tel: +1 310 301 5800
<mailto:iana@iana.org>";
description
"This module contains a collection of YANG identities defined
by IANA and used as interface types for tunnel interfaces.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8675; see
the RFC itself for full legal notices.";
revision 2019-11-16 {
description
"Initial revision.";
reference
"RFC 8675: A YANG Data Model for Tunnel Interface Types";
}
identity other {
base ift:tunnel;
description
"None of the following values.";
reference
"RFC 4087: IP Tunnel MIB";
}
identity direct {
base ift:tunnel;
description
"No intermediate header.";
reference
"RFC 2003: IP Encapsulation within IP
RFC 4213: Basic Transition Mechanisms for IPv6 Hosts
and Routers";
}
identity gre {
base ift:tunnel;
description
"GRE encapsulation.";
reference
"RFC 1701: Generic Routing Encapsulation (GRE)
RFC 1702: Generic Routing Encapsulation over IPv4 networks
RFC 7676: IPv6 Support for Generic Routing Encapsulation
(GRE)";
}
identity minimal {
base ift:tunnel;
description
"Minimal encapsulation.";
reference
"RFC 2004: Minimal Encapsulation within IP";
}
identity l2tp {
base ift:tunnel;
description
"L2TP encapsulation.";
reference
"RFC 2661: Layer Two Tunneling Protocol 'L2TP'";
}
identity pptp {
base ift:tunnel;
description
"PPTP encapsulation.";
reference
"RFC 2637: Point-to-Point Tunneling Protocol (PPTP)";
}
identity l2f {
base ift:tunnel;
description
"L2F encapsulation.";
reference
"RFC 2341: Cisco Layer Two Forwarding (Protocol) 'L2F'";
}
identity udp {
base ift:tunnel;
description
"UDP encapsulation.";
reference
"RFC 1234: Tunneling IPX Traffic through IP Networks,
RFC 8085: UDP Usage Guidelines, Section 3.1.11";
}
identity atmp {
base ift:tunnel;
description
"ATMP encapsulation.";
reference
"RFC 2107: Ascend Tunnel Management Protocol - ATMP";
}
identity msdp {
base ift:tunnel;
description
"MSDP encapsulation.";
reference
"RFC 3618: Multicast Source Discovery Protocol (MSDP)";
}
identity sixtofour {
base ift:tunnel;
description
"6to4 encapsulation.";
reference
"RFC 3056: Connection of IPv6 Domains via IPv4 Clouds";
}
identity sixoverfour {
base ift:tunnel;
description
"6over4 encapsulation.";
reference
"RFC 2529: Transmission of IPv6 over IPv4 Domains without
Explicit Tunnels";
}
identity isatap {
base ift:tunnel;
description
"ISATAP encapsulation.";
reference
"RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)";
}
identity teredo {
base ift:tunnel;
description
"Teredo encapsulation.";
reference
"RFC 4380: Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)";
}
identity iphttps {
base ift:tunnel;
description
"IP over HTTPS (IP-HTTPS) Tunneling Protocol.";
reference
"Microsoft Corporation, IP over HTTPS (IP-HTTPS) Tunneling
Protocol Specification,
https://msdn.microsoft.com/en-us/library/dd358571.aspx";
}
identity softwiremesh {
base ift:tunnel;
description
"softwire mesh tunnel.";
reference
"RFC 5565: Softwire Mesh Framework";
}
identity dslite {
base ift:tunnel;
description
"DS-Lite tunnel.";
reference
"RFC 6333: Dual-Stack Lite Broadband Deployments Following
IPv4 Exhaustion";
}
identity aplusp {
base ift:tunnel;
description
"A+P encapsulation.";
reference
"RFC 6346: The Address plus Port (A+P) Approach to the IPv4
Address Shortage";
}
}
Security ConsiderationsThe YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such as
NETCONF or RESTCONF . The lowest NETCONF layer is the
secure transport layer, and the mandatory-to-implement secure transport is
Secure Shell (SSH) . The lowest RESTCONF
layer is HTTPS, and the mandatory-to-implement secure transport is TLS
.The Network Configuration Access Control Model (NACM) 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.The module defined in this document defines YANG identities for the
iana-tunnel-types registry. These identities are intended to be
referenced by other YANG modules, and by themselves do not expose any
nodes which are writable, contain read-only state, or RPCs. As such,
there are no additional security issues to be considered relating to the
module defined in this document.IANA ConsiderationsYANG ModuleIANA has registered the following URI in the
"ns" subregistry within the "IETF XML Registry" :
URI:
urn:ietf:params:xml:ns:yang:iana-tunnel-type
Registrant Contact:
IANA
XML:
N/A; the requested URI is an XML namespace.
IANA registered the
following YANG module in the "YANG Module Names" subregistry within the "YANG Parameters" registry.
Name:
iana-tunnel-type
Namespace:
urn:ietf:params:xml:ns:yang:iana-tunnel-type
Prefix:
iana-tunnel-type
Reference:
RFC 8675
This document defines the initial version of the IANA-maintained
iana-tunnel-type YANG module. IANA has added this note to the registry:
Tunnel type values must not be directly added to the iana-tunnel-type
YANG module. They must instead be added to the "tunnelType"
subregistry (under the "ifType definitions" registry) at [IANA
registry smi-numbers].
When a tunnel type is added to the "tunnelType" subregistry, a new
"identity" statement must be added to the iana-tunnel-type YANG
module. The name of the "identity" is the lower-case of the
corresponding enumeration in the IANAifType-MIB (i.e.,
IANAtunnelType). The "identity" statement should have the following
sub-statements defined:
"base":
Contains 'ift:tunnel'.
"description":
Replicates the description
from the registry.
"reference":
Replicates the reference from
the registry and adds the title of the document.
Unassigned or reserved values are not present in the module.When the iana-tunnel-type YANG module is updated, a new "revision"
statement must be added in front of the existing revision
statements.IANA has added the following note to "tunnelType"
subregistry:
When this registry is modified, the YANG module
iana-tunnel-type must be updated as defined in RFC 8675.
Updates to the IANA tunnelType TableIANA has updated the following entries in the tunnelType registry under
the SMI Numbers registry .
OLD:
Decimal
Name
Description
References
2
direct
no intermediate header
3
gre
GRE encapsulation
4
minimal
Minimal encapsulation
5
l2tp
L2TP encapsulation
6
pptp
PPTP encapsulation
7
l2f
L2F encapsulation
8
udp
UDP encapsulation
9
atmp
ATMP encapsulation
10
msdp
MSDP encapsulation
11
sixToFour
6to4 encapsulation
12
sixOverFour
6over4 encapsulation
13
isatap
ISATAP encapsulation
14
teredo
Teredo encapsulation
16
softwireMesh
softwire mesh tunnel
17
dsLite
DS-Lite tunnel
NEW:
Decimal
Name
Description
References
2
direct
no intermediate header
3
gre
GRE encapsulation
4
minimal
Minimal encapsulation
5
l2tp
L2TP encapsulation
6
pptp
PPTP encapsulation
7
l2f
L2F encapsulation
8
udp
UDP encapsulation
9
atmp
ATMP encapsulation
10
msdp
MSDP encapsulation
11
sixToFour
6to4 encapsulation
12
sixOverFour
6over4 encapsulation
13
isatap
ISATAP encapsulation
14
teredo
Teredo encapsulation
16
softwireMesh
softwire mesh tunnel
17
dsLite
DS-Lite tunnel
ReferencesNormative ReferencesThe IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.IANA Interface Type YANG ModuleThis document defines the initial version of the iana-if-type YANG module.The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).Network Configuration Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536.Network Management Datastore Architecture (NMDA)Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Structure of Management Information (SMI) Numbers (MIB Module Registrations)IANAInformative ReferencesGuidelines and Registration Procedures for Interface Types and Tunnel TypesThis document provides guidelines and procedures for those who are defining, registering, or evaluating definitions of new interface types ("ifType" values) and tunnel types. The original definition of the IANA interface type registry predated the use of IANA Considerations sections and YANG modules, and so some confusion arose over time. Tunnel types were added later, with the same requirements and allocation policy as interface types. This document updates RFC 2863, and provides updated guidance for these registries.Work in ProgressGeneric Routing Encapsulation (GRE)This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.Generic Routing Encapsulation over IPv4 networksThis memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.IP Encapsulation within IPThis document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]Minimal Encapsulation within IPThis document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. [STANDARDS-TRACK]Ascend Tunnel Management Protocol - ATMPThis document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.Cisco Layer Two Forwarding (Protocol) "L2F"This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind.Transmission of IPv6 over IPv4 Domains without Explicit TunnelsThis memo specifies the frame format for transmission of IPv6 (IPV6) packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. [STANDARDS-TRACK]Point-to-Point Tunneling Protocol (PPTP)This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. This memo provides information for the Internet community.Layer Two Tunneling Protocol "L2TP"This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]Connection of IPv6 Domains via IPv4 CloudsThis memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS-TRACK]Multicast Source Discovery Protocol (MSDP)The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.IP Tunnel MIBThis memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. [STANDARDS-TRACK]Basic Transition Mechanisms for IPv6 Hosts and RoutersThis document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.This document obsoletes RFC 2893. [STANDARDS-TRACK]Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". [STANDARDS-TRACK]Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo provides information for the Internet community.Softwire Mesh FrameworkThe Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]Dual-Stack Lite Broadband Deployments Following IPv4 ExhaustionThis document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK]The Address plus Port (A+P) Approach to the IPv4 Address ShortageWe are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. This document defines an Experimental Protocol for the Internet community.IPv6 Support for Generic Routing Encapsulation (GRE)Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.Softwire Mesh Management Information Base (MIB)This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing a softwire mesh.Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs)This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects for Address Family Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).UDP Usage GuidelinesThe User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.YANG Tree DiagramsThis document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.A YANG Data Model for Interface ManagementThis document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.This document obsoletes RFC 7223.YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) SoftwiresExample UsageThe following example illustrates how the Interface YANG module can
be augmented with tunnel-specific parameters. In this example, the
module is augmented with a 'remote-endpoint' for the tunnel. A tree
structure is provided below:
module: example-iftunnel-extension
augment /if:interfaces/if:interface:
+--rw remote-endpoint? inet:ipv6-address
The 'example-iftunnel-extension' module imports the modules defined
in and in
addition to the "iana-tunnel-type" module defined in this document.module example-iftunnel-extension {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:example-iftunnel-extension";
prefix example;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types, Section 4";
}
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
import iana-tunnel-type {
prefix iana-tunnel-type;
reference
"RFC 8675: A Tunnel Extension to the Interface Management
YANG Module";
}
organization "IETF Softwire Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/softwire/>
WG List: <mailto:softwire@ietf.org>
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>";
description
"This is an example YANG module to extend the Interface YANG
module with tunnel-specific parameters.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8675; see
the RFC itself for full legal notices.";
revision 2019-10-21 {
description
"Initial revision.";
reference
"RFC 8675: Tunnel Interface Types YANG Module";
}
augment "/if:interfaces/if:interface" {
when "derived-from(if:type, 'iana-tunnel-type:gre')";
description
"Augments Interface module with specific tunnel parameters.";
leaf remote-endpoint {
type inet:ipv6-address;
description
"IPv6 address of the remote GRE endpoint.";
}
}
}
AcknowledgementsSpecial thanks to Tom Petch and Martin Bjorklund for the detailed
review and suggestions.Thanks to Andy Bierman for the Yangdoctors review.Thanks to Dale Worley, David Black, and Yaron Sheffer for the
review.Authors' AddressesOrangeRennes35000Francemohamed.boucadair@orange.comDeutsche Telekom AGCTO-ATI, Landgrabenweg 151BonnNRW53227Germanyian.farrer@telekom.deCisco Systems, Inc.7025 Kit Creek Rd.RTPNC27709United States of AmericaRajiva@cisco.com