<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY filename  "draft-eastlake-dnsop-rrtype-srv6-09">
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp    "&#8203;">
  <!ENTITY nbhy    "&#8209;">
  <!ENTITY wj      "&#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 compact="no" ?>
<!-- do not start each main section on a new page -->

<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="std" docName="&filename;"
     ipr="trust200902" submissionType="IETF" xml:lang="en"
     obsoletes="" updates="" tocInclude="true" tocDepth="3"
     symRefs="true" sortRefs="true"
     version="3"> 
  <!-- xml2rfc v2v3 conversion 3.12.3 -->
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
<!-- 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="The SRv6 DNS RR">
    The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource
    Record</title>
    <seriesInfo name="Internet-Draft"
		value="&filename;"/>
    
    <author fullname="Donald Eastlake" initials="D." surname="Eastlake">
      <organization>Independent</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="2026" month="February" day="27"/>
    <!-- If the month and year are both specified and are the current
       ones, xml2rfc will fill in the current day for you. If only the
       current year is specified, xml2rfc will fill in the current day
       and month for you. If the year is not the current one, it is
       necessary to specify at least a month (xml2rfc assumes day="1"
       if not specified for the purpose of calculating the expiry
       date).  With drafts it is normally sufficient to specify just
       the year. -->

  <!-- Meta-data Declarations -->

  <area/>
    <workgroup>DNSOP</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>SRv6</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) Resource Record (RR) Type is
    specified for storing IPv6 Segment Routing (SRv6) 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
      <xref target="RFC4034"/> <xref target="RFC4035"/> used for
      bi-directional mapping between domain names and addresses, for
      email routing, and for other information <xref
      target="RFC1034"/> <xref target="RFC1035"/>. 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="RFC9499"/> is assumed in this document.</t>
      
    <section anchor="SRv6" numbered="true" toc="default">
      <name>IPv6 Segment Routing</name>

      <t>Internet Protocol versions 4 (IPv4, <xref target="RFC0791"/>)
      and 6 (IPv6, <xref target="RFC8200"/>) have long provided header
      options that support including an ordered sequence of addresses
      in a packet header so the packet travels in order through the
      nodes specified by that sequence of addresses. This is sometimes
      referred to as "source routing" because the route or path the
      packet follows is set, at least in part, when the sequence of
      addresses is added to the packet, usually at the packet's
      source, rather than being dynamically determined as the packet
      proceeds through the network.</t>

      <t>IPv6 Segment Routing (SRv6, <xref target="RFC8402"/>) extends
      "source routing" by generalizing the IPv6 sized "address"
      quantities in a source "routing" sequence to be
      "instructions". <xref target="RFC8754"/> specifies a particular
      Segment Routing Header (SRH) that may be use used as part of the
      headers of an IPv6 packet to indicate an IPv6 Segment Routing
      sequence of addresses / instructions. <xref target="RFC8986"/>
      further specifies the structuring of an IPv6 address size
      quantity such that it may be composed of addressing information
      followed by a function designation which is optionally further
      followed by arguments to that function. Thus, segment routing
      might encode a series of operations to be performed on a
      packet.</t>

      <t>Furthermore, because a sequence of SRv6 instructions may all
      start with the same constant addressing prefix, methods of
      compression have been specified <xref target="RFC9800"/> to
      represent this addressing prefix less often and pack an
      increased number of quantities into a Segment Routing Header
      where each quantity may consist optionally of additional address
      information and/or function designation and/or function
      arguments.</t>

    </section>

    <section anchor="SRV6RRType" numbered="true"
	     toc="default">
      <name>The SRV6 RR Type</name>

      <t>This document specifies a SRV6 RR Type to return a sequence
      of IPv6 Segment Routing addresses / instructions and
      optionally other data.</t>

      <t>In many ways, the data returned for an SRV6 DNS RR is like an
      address. This RR supports a DNS client querying for SRV6 RRs at a
      name, inserting returned SRv6 information into the header of an
      IPv6 packet, and transmitting that packet so addressed. It would
      also be reasonable for an application using SRv6 to do a type
      SRV DNS query <xref target="RFC2782"/> followed by an SRV6 query
      at the resulting domain name if it was in a domain where SRv6
      was in use.  Furthermore, as a fall back, if no SRV6 RR is
      present in the DNS at a domain name, a client application whose
      SRV6 query has failed could query for the AAAA IPv6 address RR
      type.</t>

      <t>Segment Routing is intended to be used in a limited domain
      compared with the global Internet. Furthermore, the DNS is
      commonly thought of as the source for global Internet
      addressing. However, most DNS servers can be easily configured
      in a network so that some names are only visible locally and
      some RRs are only delivered locally.</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"/>
      <xref target="RFC8174"/> 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</li>
	<li>IANA - Internet Assigned Number Authority</li>
	<li>IPv6 - Internet Protocol Version 6 <xref
	target="RFC8200"/></li>
	<li>RR - DNS Resource Record</li>
	<li>SID - Segment Identifier <xref target="RFC8402"/></li>
	<li>SRH - Segment Routing (IPv6) Header <xref
	target="RFC8754"/></li>
	<li>SRv6 - IPv6 Segment Routing <xref target="RFC8402"/></li>
	<li>SRV6 - Mnemonic for the SRv6 RR Type</li>
	<li>TLV - Type, Length, Value</li>
      </ul>

    </section>
      
    </section>
    
    <section anchor="RDATA" numbered="true" toc="default">
      <name>SRV6 RR Type RDATA</name>
      
      <t>The SRV6 RR type enables the storage and retrieval of an
      ordered sequence of SRv6 quantities each of which is 16-bytes,
      the size of an IPv6 <xref target="RFC8200"/> address. The RDATA
      for this type of RR is a set of fields followed by a sequence of
      such quantities followed by optional data (see Figure 1) and
      will be ( 4 + N*16 + Opt ) bytes long, where N is the number of
      such quantities present and Opt is the length of the optional
      data.
      </t>
      
      <t>The RR Type Code for the SRV6 RR is TBD1.</t>
            
      <figure anchor="RDataFigure">
        <name>SRV6 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID Count  |   SRH Flags   |          SRH Tag              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|           16-byte SRv6 Address/Instruction (SID) or           |
|                    Compressed SID (CSID)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.               Additional 16-byte SRv6 SIDs/CSIDs              .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.    Optional TLVs                                              .
.................................................................
		  ]]></artwork>
      </figure>
      
      <t> The RDATA consists of a segment count followed by a flags
      byte, a 2 byte tag, and then one or more 128-bit SRv6 SIDs
      followed by optional TLV data, all as further detailed as
      follows:</t>

      <ul empty="true" spacing="normal">
	<li>SID Count - As unsigned one byte integer giving the number
	of 16-byte SRv6 SIDs or CSIDs in the RDATA.</li>
	<li>SRH Flags - This byte gives a initial value for the Flags field of
	the Segment Routing Header (SRH, <xref target="RFC8754"/>).</li>
	<li>SRH Tag - This field is a suggested value for the Tag
	field of the SRH <xref target="RFC8754"/>.</li>
	<li>SIDs/CSIDs - 16-byte SRv6 segment identifiers (SIDs, <xref
	target="RFC8402"/>) or compressed SIDs (CSIDs, <xref
	target="RFC9800"/>).</li>
	<li>Optional TLVs - Suggested TLVs for inclusion in a Segment
	Routing Header (SRH, <xref target="RFC8754"/>) created using
	this RDATA.</li>
      </ul>

      <t>
	If the RDATA length is less than ( 4 + (SID Count)*16 ) or if
	the Optional TLVs do not parse as SRH TLVs, then the RR is
	malformed and MUST be ignored.</t>

      <t>Circumstances and/or future definition of flags and TLV types
      may require, when an IPv6 packet header is contructed based on
      an SRV6 RR, that some SRH FLags be set or clear regardless of
      the SRH Flags RR field and/or that some SRH TLVs be included or
      excluded regardless of the Optional TLV in the SRH RR.</t>

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

    <t>The suggestions and comments of the following persons are
    gratefully acknowledged:</t>

    <t indent="3">tbd</t>

  </section>
  
<!-- Possibly a 'Contributors' section ... -->

  <section anchor="IANA" numbered="true" toc="default">
    <name>IANA Considerations</name>
    
      <t>IANA is requested to assign an SRV6 RR Type (TBD1) as in the
      template in Appendix A.</t>

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

    <t>For information on DNS features that improve the authentication
    of retrieved RRs, see <xref target="RFC4034"/> and <xref
    target="RFC4035"/>.</t>

    <t>For SRv6 Security Considerations, see <xref target="RFC8402"/>
    and Section 5 of <xref target="RFC8754"/>. For Security
    Considerations of SRv6 Network Programming, see <xref
    target="RFC8986"/>.</t>
  </section>
    
</middle>
  
  <!--  *****BACK MATTER ***** -->

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

    
<references>
  <name>Normative References</name>
	
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/> 
	
</references>
      
<references>
    <name>Informative References</name>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3597.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/> 
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9800.xml"/>
	
</references>
    
<section anchor="template" numbered="true" toc="default">
  <name>SRV6 RR Type Template</name>
      
  <artwork align="left"><![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.

   Enable storeage of IPv6 Segment Routing sequences in the DNS.

E. Description of the proposed RR type.
   See draft-eastlake-dnsop-rrtype-srv6

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

   Perhaps AAAA but that only returns a single IPv6 address, not an
   ordered sequence of IPv6 sized SRv6 instructions or any additional
   information.

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

   SRV6

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.

   Does not use any existing registry and 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>
