rfc-8675

A YANG Data Model for Tunnel Interface Types

M. Boucadair, I. Farrer, R. Asati

date2019-11 streamIETF areaint wgsoftwire statusPROPOSED STANDARD pages16 canonicalhttps://www.rfc-editor.org/rfc/rfc8675 doi10.17487/RFC8675

This 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.

Extracted elements (18)

design-rationale §1

The module intentionally does not add all existing IETF tunneling technologies (e.g., LISP, NSH) to the tunnelType registry; the scope is limited to reflecting the current IANA registry and defining the maintenance process, with new registrations following the IETF interface type registration procedure.

yang, registry

design-rationale §1

Tunnel-specific extensions (e.g., per-tunnel configuration parameters like remote endpoint addresses) are expected to augment the Interface YANG module (RFC 8343) in dedicated documents rather than being defined here; Appendix A illustrates the pattern with a GRE remote-endpoint example.

yang

interoperability-note §2

The iana-tunnel-type module imports 'iana-if-type' (RFC 7224) and all tunnel identities derive from the 'ift:tunnel' base identity, ensuring that implementations using the Interface YANG module can type-check tunnel interfaces against this hierarchy.

yang, netconf

normative-requirement §4.1 MUST NOT

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 SMI Numbers registry, after which IANA updates the YANG module accordingly.

yang, registry

normative-requirement §4.1 MUST

When a tunnel type is added to the 'tunnelType' subregistry, a new 'identity' statement must be added to the iana-tunnel-type YANG module, using the lower-case of the corresponding IANAifType-MIB enumeration as the identity name.

yang, registry

normative-requirement §4.1 MUST

When the iana-tunnel-type YANG module is updated, a new 'revision' statement must be added in front of the existing revision statements.

yang

protocol-element §2

The 'aplusp' identity represents the Address plus Port (A+P) encapsulation approach to the IPv4 address shortage, per RFC 6346.

yang, ip, v6ops

protocol-element §2

The 'direct' identity (decimal 2) represents tunnels with no intermediate header, covering IP-in-IP encapsulation per RFC 2003 and basic IPv6 transition per RFC 4213.

yang, ip, v6ops

protocol-element §2

The 'gre' identity (decimal 3) represents Generic Routing Encapsulation, referencing RFC 1701, RFC 1702, and RFC 7676 (IPv6 support for GRE).

yang, routing

protocol-element §2

The 'iana-tunnel-type' YANG module (namespace 'urn:ietf:params:xml:ns:yang:iana-tunnel-type') defines a collection of IANA-maintained YANG identities used as interface types for tunnel interfaces, importing 'iana-if-type' and using 'ift:tunnel' as the base identity.

yang, registry

protocol-element §2

The 'isatap' identity (decimal 13) represents Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) encapsulation per RFC 5214.

yang, v6ops

protocol-element §2

The 'sixtofour' identity (decimal 11) represents 6to4 encapsulation (RFC 3056) and 'sixoverfour' (decimal 12) represents 6over4 encapsulation (RFC 2529), both for IPv6 over IPv4 transition tunneling.

yang, v6ops, ip

protocol-element §2

The 'softwiremesh' identity (decimal 16) represents softwire mesh tunnel per RFC 5565, and 'dslite' (decimal 17) represents DS-Lite tunnel per RFC 6333, both addressing IPv4 exhaustion scenarios.

yang, v6ops, ip

protocol-element §2

The 'teredo' identity (decimal 14) represents Teredo encapsulation — tunneling IPv6 over UDP through NATs — per RFC 4380.

yang, v6ops, nat, udp

registry §4.1

This document registers the 'iana-tunnel-type' YANG module in the IANA 'YANG Module Names' subregistry with namespace 'urn:ietf:params:xml:ns:yang:iana-tunnel-type' and prefix 'iana-tunnel-type', and registers the corresponding URI in the 'IETF XML Registry'.

registry, yang

registry §4.2

This document updates the IANA 'tunnelType' subregistry (under SMI Numbers) by correcting references for entries 2–14, 16, and 17 to point to their definitive RFCs rather than only RFC 4087, and adds a note requiring the iana-tunnel-type YANG module to be updated whenever this registry is modified.

registry, yang

security-consideration §3

Access to NETCONF/RESTCONF management interfaces should be controlled using the Network Configuration Access Control Model (NACM, RFC 8341) to restrict particular users to a preconfigured subset of protocol operations and content.

security, yang, netconf

security-consideration §3

The iana-tunnel-type module exposes no writable nodes, read-only state, or RPCs; it only defines YANG identities intended to be referenced by other modules, so no additional security issues arise from this module itself. NETCONF access requires SSH transport (RFC 6242) and RESTCONF requires TLS 1.3 (RFC 8446) as mandatory-to-implement secure transports.

security, yang, netconf, tls