<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY filename "draft-eastlake-dnsop-svcb-rr-tunnel-02">
  <!ENTITY nbsp   "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY zwnbsp "&#8288;">
]>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="&filename;"
     ipr="trust200902"
     submissionType="IETF"
     category="std" consensus="true"
     tocInclude="true"
     sortRefs="true"
     symRefs="true"
     version="3">
  <!-- category values: std, bcp, info, exp, and historic ipr values:
      trust200902, noModificationTrust200902,
      noDerivativesTrust200902, or pre5378Trust200902 you can add the
      attributes updates="NNNN" and obsoletes="NNNN" they will
      automatically be output with "(if approved)" -->

<!-- ***** FRONT MATTER ***** -->

<front>
    <title abbrev="DNS Storage of Tunnel Info">
    A Domain Name System (DNS) Service Parameter and Resource
    Record for Tunneling Information</title>
    <seriesInfo name="Internet-Draft"
		value="&filename;"/>
    
    <author fullname="Donald Eastlake" initials="D." surname="Eastlake">
      <organization>Futurewei Technologies</organization>
      <address>
        <postal>
          <street>2386 Panoramic Circle</street>
          <city>Apopka</city>
          <region>FL</region>
          <code>32703</code>
          <country>US</country>
        </postal>
        <phone>+1-508-333-2270</phone>
        <email>d3e3e3@gmail.com</email>
      </address>
    </author>
    
    <author fullname="Haoyu Song" initials="H." surname="Song">
      <organization>Futurewei Technologies</organization>
      <address>
        <postal>
          <street>2220 Central Expressway</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>
          <country>US</country>
        </postal>
        <email>haoyu.song@futurewei.com</email>
      </address>
    </author>
    
    <date year="2023" month="May" day="24"/>

  <!-- Meta-data Declarations -->

  <area/>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- WG name at the upperleft corner of the doc, IETF is fine for
       individual submissions.  If this element is not present, the
       default is "Network Working Group", which is used by the RFC
       Editor as a nod to the history of the IETF. -->

    <keyword>DNS</keyword>
    <keyword>SVCB</keyword>
    <keyword>Tunnel</keyword>
    <keyword>Encapsulation</keyword>
  <!-- Keywords will be incorporated into HTML output files in a meta
       tag but they have no effect on text or nroff output. If you
       submit your draft to the RFC Editor, the keywords will be used
       for the search engine. -->

  <abstract>
    <t>A Domain Name System (DNS) Service Binding (SVCB) Service
    Parameter Type and a DNS Resource Record (RR) Type are specified
    for storing connection tunneling / encapsulation Information in
    the DNS.
    </t>
  </abstract>
  
</front>

<middle>
    <section anchor="Introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Domain Name System (DNS) is a hierarchical, distributed,
      highly available database with a variety of security features
      used for bi-directional mapping between domain names and
      addresses, for email routing, and for other information <xref
      target="RFC1034" format="default"/> <xref target="RFC1035"
      format="default"/>. This data is formatted into resource records
      (RRs) whose content type and structure are indicated by the RR
      Type field. General familiarity with the DNS and its terminology
      <xref target="RFC8499" format="default"/> is assumed in this
      document.
      </t>
      
      <section anchor="Tunnel" numbered="true" toc="default">
        <name>Tunneling</name>
	
        <t>It is common for there to be a requirement to use or some
        benefit from using a "tunnel" or encapsulation scheme when
        connecting to a service/host. For a reachability use case, see
        Section 1.3 of <xref target="RFC9012"/>.  Typically, this
        involves taking a packet with a transport header addressed to
        the ultimate destination, adding a tunnel header to the
        packet, and then adding an outer transport header before
        transmitting the packet out of a network interface (port). The
        resulting packet is illustrated in <xref target="EncapFig"
        />. (In some cases, such as IP-in-IP, the Tunneling Header may
        be null.)
	</t>
	
       <figure anchor="EncapFig">
        <name>Encapsulation</name>
	
        <artwork align="center" name="" type="" alt=""><![CDATA[
+--------------------------------------------------------------+
|                   Outer Transport Header                     |
+--------------------------------------------------------------+
|                   Tunneling Header                           |
+--------------------------------------------------------------+
|                   Inner Transport Header                     |
+--------------------------------------------------------------+
|                   Tunneled/Encapsulated Packet               |
|                                                              |
         ]]></artwork>
       </figure>

       <t>The addition of the Outer Transport and Tunneling Headers
       will lengthen packets which may result in the need for
       fragmentation. Some tunneling protocol support fragmentation but
       for those that do not, fragmentation of the Tunneled Packet
       before encapsulation may be required.
       </t>

       <t>This document specifies a Domain Name System (DNS) Service
       Binding (SVCB) Service Parameter Type and a DNS Resource Record
       (RR) Type for storing connection tunneling / encapsulation
       information in the DNS. This enables the storage and retrieval
       of tunneling information that may be needed to connect to a
       remote service or host.
       </t>
	
      </section>
      
      <section anchor="Terminology" numbered="true" toc="default">
        <name>Terminology</name>
	
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
        RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
        interpreted as described in BCP 14 <xref target="RFC2119"
        format="default"/> <xref target="RFC8174" format="default"/>
        when, and only when, they appear in all capitals, as shown
        here.</t>

	<t>The following acronyms are used in this document:</t>
        <ul empty="true" spacing="normal">
          <li>DNS - Domain Name System <xref target="RFC1034"/><xref
              target="RFC1035"/>.</li>
	  <li>IANA - Internet
              Assigned Numbers Authority &lt;www.iana.org&gt;.</li>
	  <li>RDATA - The data portion of an RR.</li>
          <li>RR - DNS Resource Record.</li>
	  <li>RRType - The type field in an RR.</li>
	  <li>SVCB - Service Binding.</li>
      </ul>

		
      </section>
    </section>
    
    <section anchor="SVCB" numbered="true" toc="default">
      <name>SVCB RR Service Parameter "tunnel"</name>

      <t> The SVCB (Service Binding) RR is specified in <xref
      target="SVCBref"/>. It provides, when used in the "Service Mode",
      for the encoding of a variety of Service Parameters to assist in
      connecting to a service.</t>

      <t>The "tunnel" SVCB Service Parameter, whose numeric key value
      is TBD1, has a value consisting of the Tunnel Type, Tunnel
      Parameters Length, and Tunnel Parameters TLVs as specified for
      the BGP Tunnel Encapsulation Attribute <xref target="RFC9012"/>
      and shown in <xref target="SVCBFigure"/>. The presentation
      format for this value is hexadecimal.
      </t>
      
      <figure anchor="SVCBFigure">
        <name>SVCB tunnel Service Parameter Value</name>
	
        <artwork align="center" name="" type="" alt=""><![CDATA[
 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3     
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Tunnel Type         |   Tunnel Parameters Length    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/           Tunnel Parameters TLVs (variable length)            /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

      <t>See further details on the fields in <xref
      target="SVCBFigure"/> where fields of the same name are
      specified in <xref target="RDATA"/>.</t>
      
    </section>

    <section anchor="RDATA" numbered="true" toc="default">
      <name>TUNNEL RR Type RDATA</name>
      
      <t>The RDATA for this RR type includes tunneling information in
      the format used in the BGP Tunnel Encapsulation Attribute <xref
      target="RFC9012" format="default"/>, a domain name that maps to
      the Inner Transport Header destination, and optional Outer
      Transport Header information, all as further explained below and
      illustrated in <xref target="RDataFigure"/>.
      </t>
      
      <t>The RRType Code for the TUNNEL RR is TBD2.</t>
      
      <figure anchor="RDataFigure">
        <name>TUNNEL RRTYPE Data</name>
	
        <artwork align="center" name="" type="" alt=""><![CDATA[
 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3     
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Priority            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Tunnel Type         |   Tunnel Parameters Length    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/           Tunnel Parameters TLVs (variable length)            /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/           Target Name (variable length)                       /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
            
<t>The fields in <xref target="RDataFigure"/> are as explained
below. The contiguous Tunnel Type, Tunnel Parameters Length, and
Tunnel Parameters TLV (Value) as a block of data are identical to the
"Tunnel Encapsulation TLV" specified in <xref target="RFC9012"/> ("The
BGP Tunnel Encapsulation Attribute").
      </t>
      
      <dl>
	<dt>Prority</dt>
	<dd><t>-  This field is a two-byte unsigned integer using
	network byte order that is the priority of using this tunnel
	to the target. A client MUST use the tunnel with the lowest
	priority RR that meets the following conditions:
        </t>
	<ol spacing="compact">
	  <li>The client implements the Tunnel Type.</li>
	  <li>The client can resolve the Target Name.</li>
	  <li>The type of packet being tunneled in not prohibited by
	  an optional Protocol Type Tunnel Parameters TLV (see Section
	  3.4.1 of <xref target="RFC9012"/>). For example, the
	  tunneling could be restricted to TCP packets.</li>
	</ol>
	</dd>
	<dt>Tunnel Type</dt>
	<dd>-  This is the Tunnel Type from the IANA "BFP Tunnel
	Encapsulation Attribute Tunnel Types" registry as specified in
	<xref target="RFC9012"/>.
	</dd>
	<dt>Tunnel Parameters Length</dt>
	<dd>-  A two-byte unsigned integer using network byte order
	giving the number of octets in the Tunnel Parameters TLVs
	field. Necessary because that field is not self-terminating.
	</dd>
	<dt>Tunnel Parameters TLVs</dt>
	<dd><t>-  This field consists of "Tunnel Encapsulation
	Attribute Sub-TLVs" as specified in <xref
	target="RFC9012"/>. These TLVs can specify a variety of
	parameters, including the following, which may be useful in
	constructing the
	Outer Transport Header (<xref target="EncapFig"/>):
      </t>
        <ul spacing="compact">
	  <li>Tunnel Egress Endpoint</li>
	  <li>Differentiated Services Field <xref target="RFC2474"/></li>
	  <li>UDP Destination Port</li>
	</ul>
	</dd>
	<dt>Target Name</dt>
	<dd>-  The uncompressed domain name of the ultimate destination
	in DNS wire encoding format. Used to obtain the destination
	address for the construction of the Inner Transport Header as
	shown in <xref target="EncapFig"/>.
	</dd>
    </dl>

    </section>

    <section>
      <name>Use of RRs</name>

 <t>A client/application seeking to send packets to a host or service
 can query the DNS using the name of the host or service for the
 TUNNEL RR. If that name is found and one or more TUNNEL RRs are
 returned, it can use the highest priority TUNNEL RR for which it has
 implemented the Tunnel Type indicated in that RR to create and
 populate a header as shown in <xref target="EncapFig"/>. The Target
 Name in that TUNNEL RR can then be used to obtain an address for use
 in the Outer Transport Header as also shown in <xref
 target="EncapFig"/>. </t>

 <t>Where a client/application is already using the SVCB RR, similar
 logic applies using the tunnel SVCB Service Parameter.</t>
 
    </section>
    
    <section anchor="Acknowledgements">
      <name>Acknowledgements</name>
      
<t>The suggestions and comments of the following persons are
gratefully acknowledged:</t>
      
      <t>tbd</t>
      
    </section>
    <!-- Possibly a 'Contributors' section ... -->

  <section anchor="IANA" numbered="true" toc="default">
    <name>IANA Considerations</name>

      <t>IANA is requested to assign a value from the Service
      Parameter Keys Registry on the "DNS Service Bindings (SVCB)"
      IANA web page as follows:</t>

      <artwork align="center"><![CDATA[
Number   Name    Meaning                Reference
------  ------  ---------------------  ---------------
 TBD1   tunnel  Tunneling information  [this document]
]]></artwork>
    
      <t>IANA is requested to assign a TUNNEL RR Type (TBD2) as in the
      template in Appendix A.</t>

  </section>
  
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      
      <t>tbd</t>
      
    </section>
    
  </middle>
  
  <!--  *****BACK MATTER ***** -->

<back>
    <!-- References split into informative and normative -->

  <!-- There are 2 ways to insert reference entries from the citation
       libraries: 1. define an ENTITY at the top, and use "ampersand
       character"RFC2629; here (as shown) 2. simply use a PI "less
       than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds:
       include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

  Both are cited textually in the same manner: by using xref elements.
  If you use the PI option, xml2rfc will, by default, try to find
  included files in the same directory as the including file. You can
  also define the XML_LIBRARY environment variable with a value
  containing a set of directories to search.  These can be either in
  the local filing system or remote ones accessed by http
  (http://domain/dir/... ).-->

  <references>
    <name>References</name>
    
      <references>
        <name>Normative References</name>
	
        <reference anchor="RFC1034"
		   target="https://www.rfc-editor.org/info/rfc1034"
		   xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"> 
          <front>
            <title>Domain names - concepts and facilities</title>
            <author initials="P.V." surname="Mockapetris"
		    fullname="P.V. Mockapetris"/> 
            <date year="1987" month="November"/>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1034"/>
          <seriesInfo name="DOI" value="10.17487/RFC1034"/>
        </reference>
	
        <reference anchor="RFC2119"
		   target="https://www.rfc-editor.org/info/rfc2119"
		   xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> 
          <front>
            <title>Key words for use in RFCs to Indicate Requirement
            Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner"/>
            <date year="1997" month="March"/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
	
        <reference anchor="RFC8174"
		   target="https://www.rfc-editor.org/info/rfc8174"
		   xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> 
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
            Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba"/>
            <date year="2017" month="May"/>
          </front>
        <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
		
        <reference anchor="RFC2474"
		   target="https://www.rfc-editor.org/info/rfc2474"
		   xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"> 
          <front>
            <title>Definition of the Differentiated Services Field (DS
            Field) in the IPv4 and IPv6 Headers</title>
            <author initials="K." surname="Nichols"/>
            <author initials="S." surname="Blake"/>
            <author initials="F." surname="Baker"/>
            <author initials="D." surname="Black"/>
            <date year="1998" month="December"/>
         </front>
          <seriesInfo name="RFC" value="2474"/>
          <seriesInfo name="DOI" value="10.17487/RFC2474"/>
        </reference>

        <reference anchor="RFC1035"
		   target="https://www.rfc-editor.org/info/rfc1035"
		   xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"> 
          <front>
            <title>Domain names - implementation and
            specification</title>
            <author initials="P.V." surname="Mockapetris"
		    fullname="P.V. Mockapetris"> 
            </author>
            <date year="1987" month="November"/>
         </front>
          <seriesInfo name="RFC" value="1035"/>
          <seriesInfo name="DOI" value="10.17487/RFC1035"/>
        </reference>

        <reference anchor="RFC3597"
		   target="https://www.rfc-editor.org/info/rfc3597"
		   xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3597.xml"> 
          <front>
            <title>Handling of Unknown DNS Resource Record (RR)
	    Types</title> 
            <author initials="A." surname="Gustafsson"/>
            <date year="2003" month="September"/>
          </front>
          <seriesInfo name="RFC" value="3597"/>
          <seriesInfo name="DOI" value="10.17487/RFC3597"/>
        </reference>

        <reference anchor="RFC9012"
		   target="https://www.rfc-editor.org/info/rfc9012"
		   xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"> 
          <front>
            <title>The BGP Tunnel Encapsulation Attribute</title> 
            <author initials="K." surname="Patel"/>
            <author initials="G." surname="Van de Velde"/>
            <author initials="S." surname="Sangli"/>
            <author initials="J." surname="Scudder"/>
            <date year="2021" month="April"/>
          </front>
          <seriesInfo name="RFC" value="9012"/>
          <seriesInfo name="DOI" value="10.17487/RFC9012"/>
        </reference>

	<reference anchor="SVCBref">
	  <front>
	    <title>Service binding and parameter specification via the
	    DNS (DNS SVCB and HTTPS RRs)</title>
	    <author initials="B." surname="Schwartz"/>
	    <author initials="M." surname="Bishop"/>
	    <author initials="E." surname="Nygren"/>
	    <date day="24" month="May" year="2022"/>
	  </front>
	  <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-10"/>
	</reference>
	
      </references>

      <references>
        <name>Informative References</name>
	
        <reference anchor="RFC8499"
		   target="https://www.rfc-editor.org/info/rfc8499"
		   xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"> 
          <front>
            <title>DNS Terminology</title>
            <author initials="P." surname="Hoffman"/>
            <author initials="A." surname="Sullivan"/>
            <author initials="K." surname="Fujiwara"/>
            <date year="2019" month="January"/>
          </front>
          <seriesInfo name="RFC" value="8499"/>
          <seriesInfo name="DOI" value="10.17487/RFC8499"/>
        </reference>

      </references>
    </references>
    
    <section anchor="template" numbered="true" toc="default">
      <name>Tunnel RR Type Template</name>
      
      <artwork name="" type="" align="left"
	       alt="TUNNEL RRType Application Template"><![CDATA[
A. Submission Date: tbd

B.1 Submission Type:  [X] New RRTYPE  [ ] Modification to RRTYPE
B.2 Kind of RR:  [X] Data RR  [ ] Meta-RR

C. Contact Information for submitter (will be publicly posted):
   Name: Donald Eastlake       Email Address: d3e3e3@gmail.com
   International telephone number: +1-508-333-2270
   Other contact handles:

D. Motivation for the new RRTYPE application.

   Need to store tunneling information in the DNS.

E. Description of the proposed RR type.
   See draft-eastlake-dnsop-svcb-rr-tunnel

F. What existing RRTYPE or RRTYPEs come closest to filling that need
   and why are they unsatisfactory?

   The SRV RR provides connection information for a service/host but
   not tunneling information.

G. What mnemonic is requested for the new RRTYPE (optional)?

   TUNNEL

H. Does the requested RRTYPE make use of any existing IANA registry
   or require the creation of a new IANA subregistry in DNS
   Parameters?  If so, please indicate which registry is to be used
   or created.  If a new subregistry is needed, specify the
   allocation policy for it and its initial contents.

   Makes use of the Border Gateway Protocol (BGP) Tunnel
   Encapsulation Registry and subsidiary Registries under tha
   encapsulation registry. Does not create a new registry.

I. Does the proposal require/expect any changes in DNS
   servers/resolvers that prevent the new type from being processed
   as an unknown RRTYPE (see [RFC3597])?

   No.

J. Comments:  None.
]]></artwork>
      
    </section>
    
  </back>
  
</rfc>
