RFC 8892

Guidelines and Registration Procedures for Interface Types and Tunnel Types

📅 published August 2020, from ietf

RFC 8892: Guidelines and Registration Procedures for Interface Types and Tunnel Types 💖

Request for Comments: 8892 📜 Category: Standards Track ✅ Date: August 2020 🗓️ Authors: D. Thaler (Microsoft) and D. Romascanu (Independent) 👩‍💻👩‍💻 Series and ISSN: IETF, ISSN 2070-1721 🌸 Updates: RFC 2863 🔄

Okay bestie, this one is the rulebook for the two registries that give names to network interface types (ifType values) and tunnel types. It's from the IETF (the Internet Engineering Task Force), and it updates RFC 2863 ✨

Abstract 🦋

This doc gives you the guidelines and procedures for anyone defining, registering, or evaluating new interface types (ifType values) and tunnel types 💅. The original interface type registry was made before IANA Considerations sections and YANG modules were a thing, so things got confusing over time 🙈. Tunnel types came later and got the same requirements and allocation policy as interface types. This document updates RFC 2863 and gives you updated guidance for these registries 🎀

Status of This Memo ✨

This is an Internet Standards Track document 🔥

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶 If you want more on Internet Standards, check Section 2 of RFC 7841 📚

Any info about the current status of this document, errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8892 🧚

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. ©️

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 🙏 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🌈

Table of Contents 🗺️

1.  Introduction
2.  Terminology
3.  Problems
4.  Interface Sub-layers and Sub-types
  4.1.  Alternate Values
5.  Available Formats
6.  Registration
  6.1.  Procedures
  6.2.  Media-Specific OID-Subtree Assignments
  6.3.  Registration Template
    6.3.1.  ifType
    6.3.2.  tunnelType
7.  IANA Considerations
  7.1.  MIB and YANG Modules
  7.2.  Transmission Number Assignments
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Authors' Addresses

1. Introduction ✨

Okay so the IANA IfType-MIB is the list of interface type (ifType) values 📋 It was first defined in [RFC1573] as its own MIB module, sitting alongside the Interfaces Group MIB (IF-MIB) module. IF-MIB got updated and now lives in [RFC2863], but the newest IF-MIB RFC doesn't include the IANA IfType-MIB anymore. Instead, IANA maintains the IANA IfType-MIB as a separate module 🏠 Same vibe with [RFC7224], which created an initial IANA Interface Type YANG Module. IANA keeps the current version of that one too 💅

The current IANA IfType registry is at [ifType-registry] 🔗 The same values also show up in [yang-if-type] and in the IANAifType textual convention at [IANAifType-MIB] 🫶

Here's the tea 🍵 Even though the ifType registry started out in a MIB module, assigning and using interface type values isn't tied to MIB modules or any other management mechanism 🌸 An interface type value can be the value of a data model object (a MIB object, a YANG object, and so on), part of a unique identifier for a data model of a given interface type (like in an OID), or just a value shown by local APIs or UIs on a device 🧚

The TUNNEL-MIB was defined in [RFC2667], which has since been obsoleted by [RFC4087] 🙃 It created a tunnelType registry ([tunnelType-registry] and the IANAtunnelType textual convention at [IANAifType-MIB]) and set the assignment policy for tunnelType values to always be identical to the policy for assigning ifType values 🔥

2. Terminology 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read the way BCP 14 [RFC2119] [RFC8174] describes, and only when they appear in all capitals, just like they do here 🎀 Lowercase versions are just regular words, bestie 🙈

3. Problems 😭

This doc tackles the following issues:

  1. As mentioned in Section 1, the original guidance was worded for MIB modules, so people got confused when using YANG modules 🤯 This doc makes it clear that ifTypes and tunnelTypes are independent of whether a data model exists, or what kind of data model it is 🦋
  2. Sub-layers and sub-types weren't well understood, even though good examples of both exist now ✨ Section 4 covers this 📚
  3. The "Interface Types (ifType)" and "Tunnel Types (tunnelType)" registries were first defined, and can still be retrieved, as MIB modules (plus other formats). So when YANG modules got added as another format, people wondered whether each format was its own separate registry 🤔 Section 5 sorts that out 💖
  4. The registries can be retrieved as MIB and YANG modules, but there was no process guidance for checking that those formats were syntactically correct when updates were made. That led to syntax errors that broke tools 😱 Section 6.1 adds a validation step to the documented assignment procedure 🛠️
  5. Some documents and registries said to send requests by email, but a web form also exists for submitting requests, which caused confusion about which one to use 📩 Section 6.1 fixes this 💅
  6. Transmission values [transmission-registry] have mostly been allocated as part of ifType allocation. But there was no guidance on whether a requester has to ask for one, and the request form had no required field for it 🙈 So IANA asked the designated expert to decide for each allocation, with no documented guidance for that expert 🫠 Section 6.2 fixes this 🎀

4. Interface Sub-layers and Sub-types 🌈

Okay, so when multiple sub-layers exist below the network layer, each sub-layer can get its own row in the ifTable with its own ifType 🧁 The ifStackTable is what shows how rows multiplex up and down 🦋 Section 3.1.1 of [RFC2863] goes into more detail, and 3.1.2 gives guidance for defining interface sub-layers 📚 But more recent experience shows that those guidelines were worded too restrictively, because MIB modules were the dominant data model back when [RFC2863] was written 🕰️

This doc makes it clear that the same guidance also applies to YANG modules 💜

Some ifTypes can define sub-types 🌸 For example, the tunnel(131) ifType defines sub-types called "tunnelTypes" 🎀 Each tunnelType can have its own MIB and/or YANG module with protocol-specific info, but there's enough overlap that some info is exposed in a generic IP Tunnel MIB that matches the tunnel(131) ifType ✨

For requests that involve multiple sub-layers below the network layer, requests MUST include (or reference) a discussion of the multiplexing relationships between the sub-layers, ideally with a diagram 📐 There are some well-written examples of this, like Section 3.4.1 of [RFC3637], Section 3.1.1 of [RFC4087], and Section 3.1.1 of [RFC5066] 👑

Definers of sub-layers and sub-types should think about which model fits their needs best 🧠 A sub-layer is generally used when either a dynamic relationship exists (meaning the set of instances above or below a given instance can change over time), or when a multiplexing relationship exists with another sub-layer 🔄 A sub-type works when neither of those is true, but one interface type is conceptually a subclass of another from a management data model point of view 💅

In general, an interface type or sub-type should be defined well enough to identify an interoperable protocol 🫶 Sometimes, though, a protocol isn't defined well enough for interoperability with other compliant implementations of that protocol 😬 In that case, the ifType definition should discuss whether specific instantiations (or profiles) of behavior should use a sub-layer model (where each vendor might layer the protocol over its own sub-layer that fills in the missing details) or a sub-type model (where each vendor might subclass the protocol without any layering relationship) 🧩 If a sub-type model fits better, the data model for the protocol might include a sub-type identifier so management software can discover objects specific to that sub-type 🔍 Either way, that discussion matters for guiding the people defining a data model for the more specific info (a lower sub-layer or a sub-type), and for the designated expert, who has to review requests for any such ifTypes or sub-types 🎀

Part 1 ends here, bestie! Section 4.1 (Alternate Values) and everything after it come in part 2 💖

4.1. Alternate Values ✨

Okay so here's the big design question 🤔 when you're making a new interface or tunnel mechanism, do you reuse an existing ifType or tunnelType value (maybe with a sub-type or sub-layer for the little differences), or do you grab a brand-new value? Bestie, this one is lowkey tricky.

If there's already an entry that could easily cover your modeling and functional needs, you SHOULD reuse it 🎀. The reason is so apps and tools that already use that value can keep working with zero changes. BUT if the modeling and functional needs are so different that having existing apps and tools use the old value would be a problem, then you SHOULD use a new value instead 💅.

Here's a juicy example 🍓 Back in the day, different ifType values got used for different flavors of Ethernet (ethernetCsmacd(6), iso88023Csmacd(7), fastEther(62), and so on), mostly because different vendors registered them. Honestly, that was a mess, because they were all functionally the same 😭. So [RFC3635] deprecated all of them except ethernetCsmacd(6). Iconic glow-up, no notes 🌸.

Another one! 🦋 A udp(8) tunnelType value was defined in [RFC2667] with the description "The value UDP indicates that the payload packet is encapsulated within a normal UDP packet (e.g., RFC 1234)." Then the Teredo tunnel protocol [RFC4380] came along, and it also encapsulates packets over UDP. But the protocol model is really different between [RFC1234] and Teredo. For example, [RFC1234] supports encapsulating multicast/broadcast traffic, and Teredo does not 🙈. So it would be super confusing for apps and tools to represent them with the same tunnel type, which is why [RFC4087] defined a new value for Teredo. Main character energy for Teredo 👑.

So here's the summary, fr fr ✨: if you're defining a new interface or tunnel mechanism, you SHOULD use a new ifType or tunnelType value instead of reusing an existing one when key things like the header format or the link model (point-to-point, non-broadcast multi-access, broadcast-capable multi-access, unidirectional broadcast, etc.) are significantly different from existing values. But if the differences can be expressed through different values of other existing objects in the standard YANG or MIB module (not ifType/tunnelType), you SHOULD reuse the same value 🫶.

5. Available Formats 🌈

Okay, registries come in lots of formats 💖. XML, HTML, CSV, and plain text are the common ones. This document makes it clear that the [IANAifType-MIB], [yang-if-type], and [yang-tunnel-type] MIB and YANG modules are just additional formats for the "Interface Types (ifType)" and "Tunnel Types (tunnelType)" registries 🧚. They are NOT separate registries, and the same values are ALWAYS present in every format of the same registry. (Okay, I'm yelling, but this matters 😭.)

Some of the confusion came from the IANA "Protocol Registries" [protocol-registries], which listed the YANG and MIB module formats separately, as if they were their own registries. Not it 🙅‍♀️. The yang-if-type and iana-tunnel-type YANG module entries said "See ifType definitions registry" and "See tunnelType registry (mib-2.interface.ifTable.ifEntry.ifType.tunnelType)" respectively, but the IANAifType-MIB entry had no such note. Section 7.1 addresses this.

6. Registration 💅

The IANA policy (using terms defined in [RFC8126]) for registration is Expert Review, for both interface types and tunnel types. The designated expert's job is to raise possible concerns about the wider implications of proposals for using and deploying interface types 🔍. It's recommended that the responsible Area Director and the IESG consider the designated expert's opinions, BUT nothing in the procedure lets the expert override properly reached IETF or working group consensus. Nope, not allowed 🙅‍♀️.

6.1. Procedures 📝

Someone who wants to register a new ifType or tunnelType value MUST do the following:

  1. Check the IANA registry to see whether there's already an entry that could easily satisfy the modeling and functional requirements for the requested entry. If there is, use it or update the existing specification. Text in an Internet-Draft, or in some permanently available, stable specification, may be written to clarify how to use an existing entry (or entries) for the purpose you want 🎀.
  2. Check the IANA registry to see whether there's already some other entry with the desired name. If there's an unrelated entry under that name, pick a different name 🙈.
  3. Prepare a registration request using the template in Section 6.3. The request can be in an Internet-Draft, submitted alone, or submitted as part of some permanently available, stable specification. It can also be submitted in some other form (as part of another document or as a stand-alone document), but then it will be treated as an "IETF Contribution" under the guidelines of [RFC5378] 📚.
  4. Submit the registration request (or a pointer to a document containing it) to IANA at iana@iana.org or, if you're requesting an ifType, via the web form at <https://www.iana.org/form/iftype> 💌.

Once IANA receives a registration request, the following steps MUST be followed:

  1. IANA checks the submission for completeness. If required info is missing or any citations are wrong, IANA will reject the request. You can resubmit a corrected one if you want 🔁.
  2. IANA requests Expert Review of the registration request against the corresponding guidelines from this document 🧐.
  3. The designated expert evaluates the request against the criteria 👀.
  4. Once the designated expert approves a registration, IANA updates [ifType-registry], [IANAifType-MIB], and [yang-if-type] to show the registration for an interface type, or [tunnelType-registry], [IANAifType-MIB], and [yang-tunnel-type] to show the registration for a tunnel type. When adding values, IANA SHOULD verify that the updated MIB module and YANG module formats are syntactically correct before publishing the update. There are various existing tools or websites that can do this check 🛠️.
  5. If the designated expert does NOT approve the registration (for any of the reasons in [RFC8126], Section 5, for example), you can resubmit a corrected request if you want, or the IESG can override the designated expert and approve it per the process in Section 3.3 of [RFC8126] 😤.

6.2. Media-Specific OID-Subtree Assignments 🧩

[IANAifType-MIB] notes:

|  The relationship between the assignment of ifType values and of
|  OIDs to particular media-specific MIBs is solely the purview of
|  IANA and is subject to change without notice.  Quite often, a
|  media-specific MIB's OID-subtree assignment within MIB-II's
|  'transmission' subtree will be the same as its ifType value.
|  However, in some circumstances this will not be the case, and
|  implementors must not pre-assume any specific relationship between
|  ifType values and transmission subtree OIDs.

The advice above stays the same, but this document streamlines the allocation procedure so that an ifType value and a transmission number value with the same value get assigned at the same time 🎁.

Rationale:

  1. This saves future effort if a transmission number is later deemed necessary, since no IANA request is needed that would then need another Expert Review 💡.
  2. The transmission numbering space isn't scarce, so there's little reason to reserve the number for a different purpose than what the ifType is for 🌸.
  3. The designated expert doesn't need to review whether a transmission number value should be registered when processing each ifType request, which reduces the chance of delaying ifType assignments 🏃‍♀️.
  4. There's no case on record where allocating the same value caused any problems 🙌.

6.3. Registration Template 📋

6.3.1. ifType 🎀

The following template describes the fields that MUST be supplied in a registration request for adding to the "Interface Types (ifType)" registry:

Label for IANA ifType requested: As explained in Section 7.1.1 of [RFC2578], a label for a named-number enumeration must consist of one or more letters or digits, up to a maximum of 64 characters, and the initial character must be a lowercase letter. (However, labels longer than 32 characters are NOT RECOMMENDED.) Note that hyphens are NOT allowed 🚫.

Name of IANA ifType requested: A short description (for example, a protocol name) that's suitable to appear in a comment in the registry 📝.

Description of the proposed use of the IANA ifType: Requesters MUST include answers, either directly or via a link to a document with the answers, to the following questions in the explanation of the proposed use of the IANA IfType 🧠:

  • How would IP run over your ifType?
  • Would there be another interface sub-layer between your ifType and IP?
  • Would your ifType be vendor specific / proprietary? (If so, the label MUST start with a string that shows that. For example, if your company's name or acronym is xxx, then the ifType label would be something like xxxSomeIfTypeLabel 🏷️.)
  • Would your ifType require or allow vendor-specific extensions? If so, would the vendor use their own ifType in a sub-layer below the requested ifType, a sub-type of the ifType, or some other mechanism?

Reference, Internet-Draft, or Specification: A link to a document is REQUIRED 🔗.

Additional information or comments: OPTIONAL; any additional comments for IANA or the designated expert 💬.

6.3.2. tunnelType 🚇✨

okay bestie, before this doc there was no form at all for tunnelType 😭 and new tunnelType requests didn't even have to use the ifType form that existed. so this doc is literally creating one 💅

the template below lists the fields that MUST be supplied in a registration request for the "Tunnel Types (tunnelType)" registry:

  • Label for IANA tunnelType requested: so, as explained in Section 7.1.1 of [RFC2578], a label for a named-number enumeration must consist of one or more letters or digits, up to a maximum of 64 characters, and the initial character must be a lowercase letter. (however, labels longer than 32 characters are not recommended.) Note that hyphens are not allowed. 🙅‍♀️🔤
  • Name of IANA tunnelType requested: a short description (e.g., a protocol name) that's suitable to show up in a comment in the registry. 🏷️
  • Description of the proposed use of the IANA tunnelType: requesters MUST include answers to the following questions in the explanation of the proposed use, either directly or via a link to a document with the answers. 🫶
    • How would IP run over your tunnelType?
    • Would there be another interface sub-layer between your tunnelType and IP?
    • Would your tunnelType be vendor-specific or proprietary? (if so, the label MUST start with a string that shows that. for example, if your company's name or acronym is xxx, then the tunnelType label would be something like xxxSomeTunnelTypeLabel.) 🏢💜
    • Would your tunnelType require or allow vendor-specific extensions? if so, would the vendor use their own tunnelType in a sub-layer below the requested tunnelType, or some sort of sub-type of the tunnelType, or some other mechanism? 🧩
  • Reference, Internet-Draft, or Specification: a link to a document is required. 🔗
  • Additional information or comments: optionally, any additional comments for IANA or the designated expert. 💬

7. IANA Considerations 📋

this entire document is about IANA considerations, but this section is the part where we talk about what IANA actually does and has to do 🙈 there are three registries affected:

  1. Interface Types (ifType) [ifType-registry]: the registration process is updated in Section 6.1, and the template is updated in Section 6.3.1.
  2. Tunnel Types (tunnelType) [tunnelType-registry]: the registration process is updated in Section 6.1, and the template is updated in Section 6.3.2.
  3. Transmission Number Values [transmission-registry]: the assignment process is updated in Section 6.2.

at the time of publication, IANA is unable to perform some of the actions requested below because of limitations in their current platform and toolset 😩 in those cases, IANA is requested to perform these actions as and when the migration to a new platform that would enable them is complete. ⏳

7.1. MIB and YANG Modules 🧠

IANA is to complete the following to clarify the relationship between MIB modules, YANG modules, and the relevant registries. this part is giving organisation era 🗂️

  1. The following note has been added to the IANAifType-MIB at [protocol-registries]: "This is one of the available formats of the Interface Types (ifType) and Tunnel Types (tunnelType) registries."
  2. The note for the iana-if-type YANG module at [protocol-registries] has been updated to read: "This is one of the available formats of the Interface Types (ifType) registry."
  3. The note for the iana-tunnel-type YANG module at [protocol-registries] has been updated to read: "This is one of the available formats of the Tunnel Types (tunnelType) registry."
  4. The new "Interface Parameters" category at [protocol-registries] includes entries for "Interface Types (ifType)" [ifType-registry], "Tunnel Types (tunnelType)" [tunnelType-registry], and "Transmission Number Values" [transmission-registry]. ✨
  5. Update the "Interface Types (ifType)" registry [ifType-registry] to list MIB [IANAifType-MIB] and YANG [yang-if-type] as Available Formats.
  6. Update the "Tunnel Types (tunnelType)" registry [tunnelType-registry] to list MIB [IANAifType-MIB] and YANG [yang-tunnel-type] as Available Formats.
  7. Replace the [yang-if-type] page with the YANG module content rather than having a page that claims to have multiple Available Formats.
  8. Replace the [yang-tunnel-type] page with the YANG module content rather than having a page that claims to have multiple Available Formats.
  9. In addition, [IANAifType-MIB] is to be updated as follows:
OLD:

|  Requests for new values should be made to IANA via email
|  (iana@iana.org).

NEW:

|  Interface types must not be directly added to the IANAifType-
|  MIB MIB module.  They must instead be added to the "Interface
|  Types (ifType)" registry at [ifType-registry].

(note that [yang-if-type] was previously updated with this language.) 📝

  1. IANA has added this document as a reference in the "Interface Types (ifType)", "Tunnel Types (tunnelType)", and "Transmission Number Values" registries, as well as the iana-if-type YANG Module, iana-tunnel-type YANG Module, and IANAifType-MIB. 📌

7.2. Transmission Number Assignments 🔢

per the discussion in Section 6.2, [ifType-registry] has been updated as follows:

OLD:

|  For every ifType registration, the corresponding transmission
|  number value should be registered or marked "Reserved".

NEW:

|  For future ifType assignments, an OID-subtree assignment MIB-II's
|  'transmission' subtree will be made with the same value.

similarly, the following change has been made to [transmission-registry]:

OLD:

|  For every transmission number registration, the corresponding
|  ifType value should be registered or marked "Reserved".

NEW:

|  For future transmission number assignments, an 'ifType' will be
|  made with the same value.

8. Security Considerations 🔐

okay this one is short but it's SO important 😭 since this document does not introduce any technology or protocol, there are no security issues to be considered for this document itself.

for security considerations related to MIB and YANG modules that expose these values, see Section 9 of [RFC2863], Section 6 of [RFC4087], and Section 3 of [RFC8675]. 🛡️💀

9. References 📚

9.1. Normative References 💖

9.2. Informative References 🌸

Authors' Addresses ✍️

Dave Thaler 💜 Microsoft Email: dthaler@microsoft.com

Dan Romascanu 🦋 Independent Email: dromasca@gmail.com

📦 where this page comes from