<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-softwire-iftunnel-07" indexInclude="true" ipr="trust200902" number="8675" prepTime="2019-11-16T22:48:45" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel-07" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8675" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Tunnel Interface Types">A YANG Data Model for Tunnel Interface Types</title>
    <seriesInfo name="RFC" value="8675" stream="IETF"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization showOnFrontPage="true">Orange</organization>
      <address>
        <postal>
          <street/>
          <city>Rennes</city>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author fullname="Ian Farrer" initials="I." surname="Farrer">
      <organization showOnFrontPage="true">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="Rajiv Asati" initials="R." surname="Asati">
      <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>7025 Kit Creek Rd.</street>
          <city>RTP</city>
          <region>NC</region>
          <code>27709</code>
          <country>United States of America</country>
        </postal>
        <email>Rajiva@cisco.com</email>
      </address>
    </author>
    <date month="11" year="2019"/>
    <workgroup>Softwire Working Group</workgroup>
    <keyword>softwire</keyword>
    <keyword>Augment tunnel</keyword>
    <keyword>tunnel management</keyword>
    <keyword>tunnel provisioning</keyword>
    <keyword>tunnel activation</keyword>
    <keyword>tunnel automation</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">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.</t>
      <t pn="section-abstract-2">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.</t>
      <t pn="section-abstract-3">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.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t pn="section-boilerplate.1-2">
            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.
        </t>
        <t pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8675" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t pn="section-boilerplate.2-1">
            Copyright (c) 2019 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-tunnel-type-yang-modul">IANA Tunnel Type YANG Module</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-yang-module">YANG Module</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-updates-to-the-iana-tunnelt">Updates to the IANA tunnelType Table</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-usage">Example Usage</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">This 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 <xref target="TUNNELTYPE-IANA-REGISTRY" format="default" sectionFormat="of" derivedContent="TUNNELTYPE-IANA-REGISTRY"/>. The
      latest revision of this module can be obtained from the IANA website.</t>
      <t pn="section-1-2">Tunnel-specific extensions may be added to the Interface module <xref target="RFC8343" format="default" sectionFormat="of" derivedContent="RFC8343"/> as a function of the tunnel type. An example of
      this is provided in <xref target="sample" format="default" sectionFormat="of" derivedContent="Appendix A"/>. 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 <xref target="RFC8676" format="default" sectionFormat="of" derivedContent="RFC8676"/>.
      Likewise, it is out of the scope of this document to update the existing
      IANA tunnelType registry <xref target="TUNNELTYPE-IANA-REGISTRY" format="default" sectionFormat="of" derivedContent="TUNNELTYPE-IANA-REGISTRY"/> with a
      comprehensive list of tunnel technologies. Guidelines and registration
      procedures for interface types and sub-types are discussed in <xref target="I-D.thaler-iftype-reg" format="default" sectionFormat="of" derivedContent="IFTYPE-REG"/>.</t>
      <t pn="section-1-3">This document uses the common YANG types defined in <xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6991"/> and adopts the Network Management Datastore
      Architecture (NMDA <xref target="RFC8342" format="default" sectionFormat="of" derivedContent="RFC8342"/>).</t>
      <t pn="section-1-4">The terminology for describing YANG modules is defined in <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/>. The meanings of the symbols used in the tree
      diagram are defined in <xref target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/>.</t>
    </section>
    <section anchor="itt" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-iana-tunnel-type-yang-modul">IANA Tunnel Type YANG Module</name>
      <t pn="section-2-1">The iana-tunnel-type module imports the 'iana-if-type' module defined
      in <xref target="RFC7224" format="default" sectionFormat="of" derivedContent="RFC7224"/>.</t>
      <t pn="section-2-2">The initial version of the module includes tunnel types defined in
      <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/>, <xref target="RFC7856" format="default" sectionFormat="of" derivedContent="RFC7856"/>, <xref target="RFC7870" format="default" sectionFormat="of" derivedContent="RFC7870"/>, and <xref target="RFC6346" format="default" sectionFormat="of" derivedContent="RFC6346"/>.</t>
      <sourcecode name="iana-tunnel-type@2019-11-16.yang" type="yang" markers="true" pn="section-2-3">
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
     &lt;mailto:iana@iana.org&gt;";
  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";
  }
}
</sourcecode>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-3-1">The YANG module specified in this document defines a schema for data
      that is designed to be accessed via network management protocols such as
      NETCONF <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/> or RESTCONF <xref target="RFC8040" format="default" sectionFormat="of" derivedContent="RFC8040"/>. The lowest NETCONF layer is the
      secure transport layer, and the mandatory-to-implement secure transport is
      Secure Shell (SSH) <xref target="RFC6242" format="default" sectionFormat="of" derivedContent="RFC6242"/>. The lowest RESTCONF
      layer is HTTPS, and the mandatory-to-implement secure transport is TLS
      <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>.</t>
      <t pn="section-3-2">The Network Configuration Access Control Model (NACM) <xref target="RFC8341" format="default" sectionFormat="of" derivedContent="RFC8341"/> 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.</t>
      <t pn="section-3-3">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.</t>
    </section>
    <section anchor="yang" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-yang-module">YANG Module</name>
        <t pn="section-4.1-1">IANA has registered the following URI in the
        "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" format="default" sectionFormat="of" derivedContent="RFC3688"/>: </t>
        <dl spacing="compact" newline="false" pn="section-4.1-2">
          <dt pn="section-4.1-2.1">URI:</dt>
          <dd pn="section-4.1-2.2">urn:ietf:params:xml:ns:yang:iana-tunnel-type</dd>
          <dt pn="section-4.1-2.3">Registrant Contact:</dt>
          <dd pn="section-4.1-2.4">IANA</dd>
          <dt pn="section-4.1-2.5">XML:</dt>
          <dd pn="section-4.1-2.6">N/A; the requested URI is an XML namespace.</dd>
        </dl>
        <t pn="section-4.1-3">IANA registered the
        following YANG module in the "YANG Module Names" subregistry <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> within the "YANG Parameters" registry.</t>
        <dl spacing="compact" newline="false" pn="section-4.1-4">
          <dt pn="section-4.1-4.1">Name:</dt>
          <dd pn="section-4.1-4.2">iana-tunnel-type</dd>
          <dt pn="section-4.1-4.3">Namespace:</dt>
          <dd pn="section-4.1-4.4">urn:ietf:params:xml:ns:yang:iana-tunnel-type</dd>
          <dt pn="section-4.1-4.5">Prefix:</dt>
          <dd pn="section-4.1-4.6">iana-tunnel-type</dd>
          <dt pn="section-4.1-4.7">Reference:</dt>
          <dd pn="section-4.1-4.8">RFC 8675</dd>
        </dl>
        <t pn="section-4.1-5">This document defines the initial version of the IANA-maintained
        iana-tunnel-type YANG module. IANA has added this note to the registry:</t>
        <ul empty="true" spacing="normal" bare="false" pn="section-4.1-6">
          <li pn="section-4.1-6.1">
        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]. 
      </li>
        </ul>
        <t pn="section-4.1-7">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:</t>
        <dl newline="false" spacing="normal" indent="15" pn="section-4.1-8">
          <dt pn="section-4.1-8.1">"base":</dt>
          <dd pn="section-4.1-8.2">Contains 'ift:tunnel'.</dd>
          <dt pn="section-4.1-8.3">"description":</dt>
          <dd pn="section-4.1-8.4">Replicates the description
            from the registry.</dd>
          <dt pn="section-4.1-8.5">"reference":</dt>
          <dd pn="section-4.1-8.6">Replicates the reference from
            the registry and adds the title of the document.</dd>
        </dl>
        <t pn="section-4.1-9">Unassigned or reserved values are not present in the module.</t>
        <t pn="section-4.1-10">When the iana-tunnel-type YANG module is updated, a new "revision"
        statement must be added in front of the existing revision
        statements.</t>
        <t pn="section-4.1-11">IANA has added the following note to "tunnelType"
        subregistry:</t>
        <ul empty="true" spacing="normal" bare="false" pn="section-4.1-12">
          <li pn="section-4.1-12.1">When this registry is modified, the YANG module
            iana-tunnel-type must be updated as defined in RFC 8675.</li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-updates-to-the-iana-tunnelt">Updates to the IANA tunnelType Table</name>
        <t pn="section-4.2-1">IANA has updated the following entries in the tunnelType registry under
	the SMI Numbers registry <xref target="TUNNELTYPE-IANA-REGISTRY" format="default" sectionFormat="of" derivedContent="TUNNELTYPE-IANA-REGISTRY"/>.
        </t>
        <t pn="section-4.2-2">OLD:</t>
        <table align="center" pn="table-1">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Decimal</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">References</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">2</td>
              <td align="left" colspan="1" rowspan="1">direct</td>
              <td align="left" colspan="1" rowspan="1">no intermediate header</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">3</td>
              <td align="left" colspan="1" rowspan="1">gre</td>
              <td align="left" colspan="1" rowspan="1">GRE encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">minimal</td>
              <td align="left" colspan="1" rowspan="1">Minimal encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">l2tp</td>
              <td align="left" colspan="1" rowspan="1">L2TP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">6</td>
              <td align="left" colspan="1" rowspan="1">pptp</td>
              <td align="left" colspan="1" rowspan="1">PPTP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">7</td>
              <td align="left" colspan="1" rowspan="1">l2f</td>
              <td align="left" colspan="1" rowspan="1">L2F encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">8</td>
              <td align="left" colspan="1" rowspan="1">udp</td>
              <td align="left" colspan="1" rowspan="1">UDP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">9</td>
              <td align="left" colspan="1" rowspan="1">atmp</td>
              <td align="left" colspan="1" rowspan="1">ATMP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">10</td>
              <td align="left" colspan="1" rowspan="1">msdp</td>
              <td align="left" colspan="1" rowspan="1">MSDP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">11</td>
              <td align="left" colspan="1" rowspan="1">sixToFour</td>
              <td align="left" colspan="1" rowspan="1">6to4 encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">12</td>
              <td align="left" colspan="1" rowspan="1">sixOverFour</td>
              <td align="left" colspan="1" rowspan="1">6over4 encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">13</td>
              <td align="left" colspan="1" rowspan="1">isatap</td>
              <td align="left" colspan="1" rowspan="1">ISATAP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">14</td>
              <td align="left" colspan="1" rowspan="1">teredo</td>
              <td align="left" colspan="1" rowspan="1">Teredo encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4087" format="default" sectionFormat="of" derivedContent="RFC4087"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">16</td>
              <td align="left" colspan="1" rowspan="1">softwireMesh</td>
              <td align="left" colspan="1" rowspan="1">softwire mesh tunnel</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC7856" format="default" sectionFormat="of" derivedContent="RFC7856"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">17</td>
              <td align="left" colspan="1" rowspan="1">dsLite</td>
              <td align="left" colspan="1" rowspan="1">DS-Lite tunnel</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC7870" format="default" sectionFormat="of" derivedContent="RFC7870"/></td>
            </tr>
          </tbody>
        </table>
        <t pn="section-4.2-4">NEW:</t>
        <table align="center" pn="table-2">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Decimal</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">References</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">2</td>
              <td align="left" colspan="1" rowspan="1">direct</td>
              <td align="left" colspan="1" rowspan="1">no intermediate header</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2003" format="default" sectionFormat="of" derivedContent="RFC2003"/><xref target="RFC4213" format="default" sectionFormat="of" derivedContent="RFC4213"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">3</td>
              <td align="left" colspan="1" rowspan="1">gre</td>
              <td align="left" colspan="1" rowspan="1">GRE encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC1701" format="default" sectionFormat="of" derivedContent="RFC1701"/><xref target="RFC1702" format="default" sectionFormat="of" derivedContent="RFC1702"/><xref target="RFC7676" format="default" sectionFormat="of" derivedContent="RFC7676"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">minimal</td>
              <td align="left" colspan="1" rowspan="1">Minimal encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2004" format="default" sectionFormat="of" derivedContent="RFC2004"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">l2tp</td>
              <td align="left" colspan="1" rowspan="1">L2TP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2661" format="default" sectionFormat="of" derivedContent="RFC2661"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">6</td>
              <td align="left" colspan="1" rowspan="1">pptp</td>
              <td align="left" colspan="1" rowspan="1">PPTP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2637" format="default" sectionFormat="of" derivedContent="RFC2637"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">7</td>
              <td align="left" colspan="1" rowspan="1">l2f</td>
              <td align="left" colspan="1" rowspan="1">L2F encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2341" format="default" sectionFormat="of" derivedContent="RFC2341"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">8</td>
              <td align="left" colspan="1" rowspan="1">udp</td>
              <td align="left" colspan="1" rowspan="1">UDP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8085" format="default" sectionFormat="of" derivedContent="RFC8085"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">9</td>
              <td align="left" colspan="1" rowspan="1">atmp</td>
              <td align="left" colspan="1" rowspan="1">ATMP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2107" format="default" sectionFormat="of" derivedContent="RFC2107"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">10</td>
              <td align="left" colspan="1" rowspan="1">msdp</td>
              <td align="left" colspan="1" rowspan="1">MSDP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC3618" format="default" sectionFormat="of" derivedContent="RFC3618"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">11</td>
              <td align="left" colspan="1" rowspan="1">sixToFour</td>
              <td align="left" colspan="1" rowspan="1">6to4 encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC3056" format="default" sectionFormat="of" derivedContent="RFC3056"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">12</td>
              <td align="left" colspan="1" rowspan="1">sixOverFour</td>
              <td align="left" colspan="1" rowspan="1">6over4 encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2529" format="default" sectionFormat="of" derivedContent="RFC2529"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">13</td>
              <td align="left" colspan="1" rowspan="1">isatap</td>
              <td align="left" colspan="1" rowspan="1">ISATAP encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5214" format="default" sectionFormat="of" derivedContent="RFC5214"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">14</td>
              <td align="left" colspan="1" rowspan="1">teredo</td>
              <td align="left" colspan="1" rowspan="1">Teredo encapsulation</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4380" format="default" sectionFormat="of" derivedContent="RFC4380"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">16</td>
              <td align="left" colspan="1" rowspan="1">softwireMesh</td>
              <td align="left" colspan="1" rowspan="1">softwire mesh tunnel</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5565" format="default" sectionFormat="of" derivedContent="RFC5565"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">17</td>
              <td align="left" colspan="1" rowspan="1">dsLite</td>
              <td align="left" colspan="1" rowspan="1">DS-Lite tunnel</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC6333" format="default" sectionFormat="of" derivedContent="RFC6333"/></td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.thaler-iftype-reg" to="IFTYPE-REG"/>
    <references pn="section-5">
      <name slugifiedName="name-references">References</name>
      <references pn="section-5.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" quoteTitle="true" derivedAnchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author initials="M." surname="Mealling" fullname="M. Mealling">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="January"/>
            <abstract>
              <t>This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" quoteTitle="true" derivedAnchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author initials="R." surname="Enns" fullname="R. Enns" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Bierman" fullname="A. Bierman" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t>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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6242" quoteTitle="true" derivedAnchor="RFC6242">
          <front>
            <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
            <author initials="M." surname="Wasserman" fullname="M. Wasserman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t>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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6242"/>
          <seriesInfo name="DOI" value="10.17487/RFC6242"/>
        </reference>
        <reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6991" quoteTitle="true" derivedAnchor="RFC6991">
          <front>
            <title>Common YANG Data Types</title>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="July"/>
            <abstract>
              <t>This document introduces a collection of common data types to be used with the YANG data modeling language.  This document obsoletes RFC 6021.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6991"/>
          <seriesInfo name="DOI" value="10.17487/RFC6991"/>
        </reference>
        <reference anchor="RFC7224" target="https://www.rfc-editor.org/info/rfc7224" quoteTitle="true" derivedAnchor="RFC7224">
          <front>
            <title>IANA Interface Type YANG Module</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="May"/>
            <abstract>
              <t>This document defines the initial version of the iana-if-type YANG module.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7224"/>
          <seriesInfo name="DOI" value="10.17487/RFC7224"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" quoteTitle="true" derivedAnchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t>YANG 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).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" quoteTitle="true" derivedAnchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="January"/>
            <abstract>
              <t>This 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).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8341" quoteTitle="true" derivedAnchor="RFC8341">
          <front>
            <title>Network Configuration Access Control Model</title>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t>The 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.</t>
              <t>This document obsoletes RFC 6536.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="91"/>
          <seriesInfo name="RFC" value="8341"/>
          <seriesInfo name="DOI" value="10.17487/RFC8341"/>
        </reference>
        <reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8342" quoteTitle="true" derivedAnchor="RFC8342">
          <front>
            <title>Network Management Datastore Architecture (NMDA)</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Shafer" fullname="P. Shafer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Wilton" fullname="R. Wilton">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8342"/>
          <seriesInfo name="DOI" value="10.17487/RFC8342"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="August"/>
            <abstract>
              <t>This 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.</t>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="TUNNELTYPE-IANA-REGISTRY" target="https://www.iana.org/assignments/smi-numbers" quoteTitle="true" derivedAnchor="TUNNELTYPE-IANA-REGISTRY">
          <front>
            <title>Structure of Management Information (SMI) Numbers (MIB Module Registrations)</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
      </references>
      <references pn="section-5.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.thaler-iftype-reg" quoteTitle="true" target="https://tools.ietf.org/html/draft-thaler-iftype-reg-06" derivedAnchor="IFTYPE-REG">
          <front>
            <title>Guidelines and Registration Procedures for Interface Types and Tunnel Types</title>
            <author initials="D" surname="Thaler" fullname="Dave Thaler">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D" surname="Romascanu" fullname="Dan Romascanu">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="November" day="2" year="2019"/>
            <abstract>
              <t>This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-thaler-iftype-reg-06"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-thaler-iftype-reg-06.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC1701" target="https://www.rfc-editor.org/info/rfc1701" quoteTitle="true" derivedAnchor="RFC1701">
          <front>
            <title>Generic Routing Encapsulation (GRE)</title>
            <author initials="S." surname="Hanks" fullname="S. Hanks">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Farinacci" fullname="D. Farinacci">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Traina" fullname="P. Traina">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1994" month="October"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1701"/>
          <seriesInfo name="DOI" value="10.17487/RFC1701"/>
        </reference>
        <reference anchor="RFC1702" target="https://www.rfc-editor.org/info/rfc1702" quoteTitle="true" derivedAnchor="RFC1702">
          <front>
            <title>Generic Routing Encapsulation over IPv4 networks</title>
            <author initials="S." surname="Hanks" fullname="S. Hanks">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Farinacci" fullname="D. Farinacci">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Traina" fullname="P. Traina">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1994" month="October"/>
            <abstract>
              <t>This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1702"/>
          <seriesInfo name="DOI" value="10.17487/RFC1702"/>
        </reference>
        <reference anchor="RFC2003" target="https://www.rfc-editor.org/info/rfc2003" quoteTitle="true" derivedAnchor="RFC2003">
          <front>
            <title>IP Encapsulation within IP</title>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1996" month="October"/>
            <abstract>
              <t>This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2003"/>
          <seriesInfo name="DOI" value="10.17487/RFC2003"/>
        </reference>
        <reference anchor="RFC2004" target="https://www.rfc-editor.org/info/rfc2004" quoteTitle="true" derivedAnchor="RFC2004">
          <front>
            <title>Minimal Encapsulation within IP</title>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1996" month="October"/>
            <abstract>
              <t>This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2004"/>
          <seriesInfo name="DOI" value="10.17487/RFC2004"/>
        </reference>
        <reference anchor="RFC2107" target="https://www.rfc-editor.org/info/rfc2107" quoteTitle="true" derivedAnchor="RFC2107">
          <front>
            <title>Ascend Tunnel Management Protocol - ATMP</title>
            <author initials="K." surname="Hamzeh" fullname="K. Hamzeh">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="February"/>
            <abstract>
              <t>This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2107"/>
          <seriesInfo name="DOI" value="10.17487/RFC2107"/>
        </reference>
        <reference anchor="RFC2341" target="https://www.rfc-editor.org/info/rfc2341" quoteTitle="true" derivedAnchor="RFC2341">
          <front>
            <title>Cisco Layer Two Forwarding (Protocol) "L2F"</title>
            <author initials="A." surname="Valencia" fullname="A. Valencia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Littlewood" fullname="M. Littlewood">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Kolar" fullname="T. Kolar">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1998" month="May"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2341"/>
          <seriesInfo name="DOI" value="10.17487/RFC2341"/>
        </reference>
        <reference anchor="RFC2529" target="https://www.rfc-editor.org/info/rfc2529" quoteTitle="true" derivedAnchor="RFC2529">
          <front>
            <title>Transmission of IPv6 over IPv4 Domains without Explicit Tunnels</title>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jung" fullname="C. Jung">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1999" month="March"/>
            <abstract>
              <t>This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2529"/>
          <seriesInfo name="DOI" value="10.17487/RFC2529"/>
        </reference>
        <reference anchor="RFC2637" target="https://www.rfc-editor.org/info/rfc2637" quoteTitle="true" derivedAnchor="RFC2637">
          <front>
            <title>Point-to-Point Tunneling Protocol (PPTP)</title>
            <author initials="K." surname="Hamzeh" fullname="K. Hamzeh">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Pall" fullname="G. Pall">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Verthein" fullname="W. Verthein">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Taarud" fullname="J. Taarud">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Little" fullname="W. Little">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Zorn" fullname="G. Zorn">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1999" month="July"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2637"/>
          <seriesInfo name="DOI" value="10.17487/RFC2637"/>
        </reference>
        <reference anchor="RFC2661" target="https://www.rfc-editor.org/info/rfc2661" quoteTitle="true" derivedAnchor="RFC2661">
          <front>
            <title>Layer Two Tunneling Protocol "L2TP"</title>
            <author initials="W." surname="Townsley" fullname="W. Townsley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Valencia" fullname="A. Valencia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Rubens" fullname="A. Rubens">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Pall" fullname="G. Pall">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Zorn" fullname="G. Zorn">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Palter" fullname="B. Palter">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1999" month="August"/>
            <abstract>
              <t>This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2661"/>
          <seriesInfo name="DOI" value="10.17487/RFC2661"/>
        </reference>
        <reference anchor="RFC3056" target="https://www.rfc-editor.org/info/rfc3056" quoteTitle="true" derivedAnchor="RFC3056">
          <front>
            <title>Connection of IPv6 Domains via IPv4 Clouds</title>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Moore" fullname="K. Moore">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2001" month="February"/>
            <abstract>
              <t>This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3056"/>
          <seriesInfo name="DOI" value="10.17487/RFC3056"/>
        </reference>
        <reference anchor="RFC3618" target="https://www.rfc-editor.org/info/rfc3618" quoteTitle="true" derivedAnchor="RFC3618">
          <front>
            <title>Multicast Source Discovery Protocol (MSDP)</title>
            <author initials="B." surname="Fenner" fullname="B. Fenner" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Meyer" fullname="D. Meyer" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="October"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3618"/>
          <seriesInfo name="DOI" value="10.17487/RFC3618"/>
        </reference>
        <reference anchor="RFC4087" target="https://www.rfc-editor.org/info/rfc4087" quoteTitle="true" derivedAnchor="RFC4087">
          <front>
            <title>IP Tunnel MIB</title>
            <author initials="D." surname="Thaler" fullname="D. Thaler">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="June"/>
            <abstract>
              <t>This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4087"/>
          <seriesInfo name="DOI" value="10.17487/RFC4087"/>
        </reference>
        <reference anchor="RFC4213" target="https://www.rfc-editor.org/info/rfc4213" quoteTitle="true" derivedAnchor="RFC4213">
          <front>
            <title>Basic Transition Mechanisms for IPv6 Hosts and Routers</title>
            <author initials="E." surname="Nordmark" fullname="E. Nordmark">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Gilligan" fullname="R. Gilligan">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="October"/>
            <abstract>
              <t>This 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.</t>
              <t>This document obsoletes RFC 2893.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4213"/>
          <seriesInfo name="DOI" value="10.17487/RFC4213"/>
        </reference>
        <reference anchor="RFC4380" target="https://www.rfc-editor.org/info/rfc4380" quoteTitle="true" derivedAnchor="RFC4380">
          <front>
            <title>Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)</title>
            <author initials="C." surname="Huitema" fullname="C. Huitema">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="February"/>
            <abstract>
              <t>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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4380"/>
          <seriesInfo name="DOI" value="10.17487/RFC4380"/>
        </reference>
        <reference anchor="RFC5214" target="https://www.rfc-editor.org/info/rfc5214" quoteTitle="true" derivedAnchor="RFC5214">
          <front>
            <title>Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)</title>
            <author initials="F." surname="Templin" fullname="F. Templin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Gleeson" fullname="T. Gleeson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Thaler" fullname="D. Thaler">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="March"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5214"/>
          <seriesInfo name="DOI" value="10.17487/RFC5214"/>
        </reference>
        <reference anchor="RFC5565" target="https://www.rfc-editor.org/info/rfc5565" quoteTitle="true" derivedAnchor="RFC5565">
          <front>
            <title>Softwire Mesh Framework</title>
            <author initials="J." surname="Wu" fullname="J. Wu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Cui" fullname="Y. Cui">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Metz" fullname="C. Metz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rosen" fullname="E. Rosen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="June"/>
            <abstract>
              <t>The 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5565"/>
          <seriesInfo name="DOI" value="10.17487/RFC5565"/>
        </reference>
        <reference anchor="RFC6333" target="https://www.rfc-editor.org/info/rfc6333" quoteTitle="true" derivedAnchor="RFC6333">
          <front>
            <title>Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion</title>
            <author initials="A." surname="Durand" fullname="A. Durand">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Droms" fullname="R. Droms">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Woodyatt" fullname="J. Woodyatt">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Lee" fullname="Y. Lee">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="August"/>
            <abstract>
              <t>This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6333"/>
          <seriesInfo name="DOI" value="10.17487/RFC6333"/>
        </reference>
        <reference anchor="RFC6346" target="https://www.rfc-editor.org/info/rfc6346" quoteTitle="true" derivedAnchor="RFC6346">
          <front>
            <title>The Address plus Port (A+P) Approach to the IPv4 Address Shortage</title>
            <author initials="R." surname="Bush" fullname="R. Bush" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="August"/>
            <abstract>
              <t>We 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.</t>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6346"/>
          <seriesInfo name="DOI" value="10.17487/RFC6346"/>
        </reference>
        <reference anchor="RFC7676" target="https://www.rfc-editor.org/info/rfc7676" quoteTitle="true" derivedAnchor="RFC7676">
          <front>
            <title>IPv6 Support for Generic Routing Encapsulation (GRE)</title>
            <author initials="C." surname="Pignataro" fullname="C. Pignataro">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Bonica" fullname="R. Bonica">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Krishnan" fullname="S. Krishnan">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="October"/>
            <abstract>
              <t>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.</t>
              <t>This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7676"/>
          <seriesInfo name="DOI" value="10.17487/RFC7676"/>
        </reference>
        <reference anchor="RFC7856" target="https://www.rfc-editor.org/info/rfc7856" quoteTitle="true" derivedAnchor="RFC7856">
          <front>
            <title>Softwire Mesh Management Information Base (MIB)</title>
            <author initials="Y." surname="Cui" fullname="Y. Cui">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Dong" fullname="J. Dong">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Wu" fullname="P. Wu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Xu" fullname="M. Xu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Yla-Jaaski" fullname="A. Yla-Jaaski">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="May"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7856"/>
          <seriesInfo name="DOI" value="10.17487/RFC7856"/>
        </reference>
        <reference anchor="RFC7870" target="https://www.rfc-editor.org/info/rfc7870" quoteTitle="true" derivedAnchor="RFC7870">
          <front>
            <title>Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs)</title>
            <author initials="Y." surname="Fu" fullname="Y. Fu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Jiang" fullname="S. Jiang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Dong" fullname="J. Dong">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Chen" fullname="Y. Chen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="June"/>
            <abstract>
              <t>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).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7870"/>
          <seriesInfo name="DOI" value="10.17487/RFC7870"/>
        </reference>
        <reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8085" quoteTitle="true" derivedAnchor="RFC8085">
          <front>
            <title>UDP Usage Guidelines</title>
            <author initials="L." surname="Eggert" fullname="L. Eggert">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Shepherd" fullname="G. Shepherd">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="March"/>
            <abstract>
              <t>The 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.</t>
              <t>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.</t>
              <t>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.</t>
              <t>This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="145"/>
          <seriesInfo name="RFC" value="8085"/>
          <seriesInfo name="DOI" value="10.17487/RFC8085"/>
        </reference>
        <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" quoteTitle="true" derivedAnchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Berger" fullname="L. Berger" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t>This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
        <reference anchor="RFC8343" target="https://www.rfc-editor.org/info/rfc8343" quoteTitle="true" derivedAnchor="RFC8343">
          <front>
            <title>A YANG Data Model for Interface Management</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t>This 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).</t>
              <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t>
              <t>This document obsoletes RFC 7223.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8343"/>
          <seriesInfo name="DOI" value="10.17487/RFC8343"/>
        </reference>
        <reference anchor="RFC8676" target="https://www.rfc-editor.org/info/rfc8676" quoteTitle="true" derivedAnchor="RFC8676">
          <front>
            <title>YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires</title>
            <author initials="I" surname="Farrer" fullname="Ian Farrer" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="November" year="2019"/>
          </front>
          <seriesInfo name="RFC" value="8676"/>
          <seriesInfo name="DOI" value="10.17487/RFC8676"/>
        </reference>
      </references>
    </references>
    <section anchor="sample" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-example-usage">Example Usage</name>
      <t pn="section-appendix.a-1">The 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:</t>
      <sourcecode name="" type="yangtree" markers="false" pn="section-appendix.a-2">
module: example-iftunnel-extension
  augment /if:interfaces/if:interface:
    +--rw remote-endpoint?   inet:ipv6-address
</sourcecode>
      <t pn="section-appendix.a-3">The 'example-iftunnel-extension' module imports the modules defined
      in <xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6991"/> and <xref target="RFC8343" format="default" sectionFormat="of" derivedContent="RFC8343"/> in
      addition to the "iana-tunnel-type" module defined in this document.</t>
      <sourcecode name="" type="yang" markers="false" pn="section-appendix.a-4">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:   &lt;https://datatracker.ietf.org/wg/softwire/&gt;
     WG List:  &lt;mailto:softwire@ietf.org&gt;

     Author:  Mohamed Boucadair 
              &lt;mailto:mohamed.boucadair@orange.com&gt;";
     
   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.";
    }   
  }
}
</sourcecode>
    </section>
    <section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t pn="section-appendix.b-1">Special thanks to Tom Petch and Martin Bjorklund for the detailed
      review and suggestions.</t>
      <t pn="section-appendix.b-2">Thanks to Andy Bierman for the Yangdoctors review.</t>
      <t pn="section-appendix.b-3">Thanks to Dale Worley, David Black, and Yaron Sheffer for the
      review.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
        <organization showOnFrontPage="true">Orange</organization>
        <address>
          <postal>
            <street/>
            <city>Rennes</city>
            <code>35000</code>
            <country>France</country>
          </postal>
          <email>mohamed.boucadair@orange.com</email>
        </address>
      </author>
      <author fullname="Ian Farrer" initials="I." surname="Farrer">
        <organization showOnFrontPage="true">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="Rajiv Asati" initials="R." surname="Asati">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street>7025 Kit Creek Rd.</street>
            <city>RTP</city>
            <region>NC</region>
            <code>27709</code>
            <country>United States of America</country>
          </postal>
          <email>Rajiva@cisco.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>