Guidelines and Registration Procedures for Interface Types and Tunnel Types
updates
- rfc-2863 — The Interfaces Group MIB
Extracted elements (19)
A new value should be used (rather than reusing an existing one) when key aspects such as header format or link model are significantly different; conversely, the same value should be reused when differences can be expressed via other YANG/MIB objects. The Teredo vs. UDP(8) example illustrates this.
A sub-layer model is generally used when a dynamic or multiplexing relationship exists between interface layers. A sub-type model is appropriate when one interface type is conceptually a subclass of another without dynamic or multiplexing relationships.
Existing applications should be considered when deciding whether to reuse an existing ifType/tunnelType or define a new one. Different Ethernet flavors were originally registered with distinct values but were later deprecated in favor of ethernetCsmacd(6) because functional similarity made separate values problematic.
ifType and tunnelType values are independent from the type of, or even existence of, a data model. Though originally defined in MIB modules, these values can be used in YANG objects, as part of OIDs, or simply as values exposed by local APIs or UIs.
MIB and YANG modules (IANAifType-MIB, yang-if-type, yang-tunnel-type) are merely additional formats in which the ifType and tunnelType registries are available — they are not separate registries, and the same values always appear in all formats.
Transmission number values are co-assigned with ifType values automatically to save future effort, because the numbering space is not scarce, to reduce designated expert review burden, and because no historical case exists where co-allocation caused problems.
The intent of an interface type or sub-type definition should be sufficient to identify an interoperable protocol. If not, the definition should discuss whether specific instantiations should use a sub-layer or sub-type model to achieve interoperability.
The relationship between ifType values and OID assignments in the MIB-II 'transmission' subtree is solely the purview of IANA; implementors must not pre-assume any specific relationship between ifType values and transmission subtree OIDs.
For requests involving multiple sub-layers below the network layer, requests MUST include (or reference) a discussion of the multiplexing relationships between sub-layers, ideally with a diagram.
IANA MUST verify that updated MIB and YANG module formats are syntactically correct before publishing registry updates. Various existing tools or websites can be used to do this verification.
If a vendor-specific ifType or tunnelType is requested, the label MUST start with a string that identifies the vendor (e.g., company name or acronym as prefix).
Requests for new ifType or tunnelType values MUST include answers to questions about how IP would run over the type, whether there would be another sub-layer between the type and IP, whether it would be vendor-specific, and whether it would require vendor-specific extensions.
Someone wishing to register a new ifType or tunnelType value MUST check the IANA registry for existing entries that could satisfy requirements, check for name conflicts, prepare a registration request using the specified template, and submit to IANA.
The ifType registration template requires: a label (lowercase-initial, alphanumeric, max 64 chars, no hyphens), a name/short description, a description of proposed use answering IP-layering and vendor-specificity questions, and a reference to a specification.
The tunnelType registration template requires: a label (same naming rules as ifType), a name/short description, a description of proposed use answering IP-layering and vendor-specificity questions, and a reference to a specification.
The 'Interface Types (ifType)' registry at IANA is updated by this document with a new registration process (Section 6.1) and updated template (Section 6.3.1). The registry is also available in MIB (IANAifType-MIB) and YANG (iana-if-type) formats.
The 'Transmission Number Values' registry assignment process is updated so that for every future ifType assignment, an OID-subtree assignment in MIB-II's 'transmission' subtree will be made with the same value automatically.
The 'Tunnel Types (tunnelType)' registry at IANA is updated with a new registration process (Section 6.1) and a newly defined registration template (Section 6.3.2). This document is the first to specify a dedicated tunnelType registration form.
This document does not introduce any technology or protocol, so there are no security issues specific to the document itself. For security considerations related to MIB and YANG modules that expose ifType/tunnelType values, see RFC 2863 Section 9, RFC 4087 Section 6, and RFC 8675 Section 3.