<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-dong-dnsop-dns-record-amr-00"
     ipr="trust200902">
  <front>
    <title abbrev="AMR">DNS-Based Address Mappping Record (AMR) for IPv4/IPv6
    Mapping in IPv6-only Networks</title>

    <author fullname="Guozhen Dong" initials="G" surname="Dong">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>guozhen.dong@foxmail.com</email>
      </address>
    </author>

    <author fullname="Chongfeng Xie" initials="C" surname="Xie">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>xiechf@chinatelecom.cn</email>
      </address>
    </author>

    <date day="7" month="July" year="2025"/>

    <workgroup>DNSOP Working Group</workgroup>

    <keyword>RFC</keyword>

    <abstract>
      <t>This document defines a new Domain Name System (DNS) resource record
      type called the Address Mapping Record (AMR). The AMR record enables
      querying of IPv6 mapping prefixes associated with the destination
      address of an IPv4 packet in IPv6-only networks. This mechanism
      facilities the transmission of IPv4 service data across multi-domain in
      IPv6-only environment, supporting IPv4-as-a-Service (IPv4aaS)
      implementations.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t><xref target="I-D.ietf-v6ops-framework-md-ipv6only-underlay"/>
      describes a framework for deploying IPv6-only underlay in multi-domain
      networks, IPv4 packets are statelessly translated or encapsulated into
      IPv6 packets for transmission. This framework requires IPv4/IPv6 address
      mapping rule to support stateless packet conversion at Provider Edge
      (PE) routers.</t>

      <t>This document defines a new Domain Name System (DNS) resource record
      type, called the Address Mapping Record (AMR). AMR record
      stores&nbsp;the&nbsp;mappings between IPv4 address blocks and their
      corresponding IPv6 prefixes, enabling PE to query&nbsp;these
      mappings&nbsp;via standard DNS protocols. AMR is applicable in IPv6-only
      networks <xref
      target="I-D.ietf-v6ops-framework-md-ipv6only-underlay"/>.</t>
    </section>

    <section title="Conventions used in this document">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref target="RFC2119"/>
      .</t>
    </section>

    <section title="Terminology">
      <t>The following terms are defined in this draft:<list style="symbols">
          <t>DNS: Domain Name System, defined in <xref target="RFC1034"/><xref
          target="RFC1035"/></t>

          <t>PE: Provider Edge, defined in <xref target="RFC4026"/></t>

          <t>Pref6: IPv6 Mapping Prefix, indicating edge devices for
          translating IPv4 packets in an IPv6-only network.</t>
        </list></t>

      <t/>
    </section>

    <section title="AMR Record Format">
      <section title="Record Name Construction">
        <t>AMR records use a special domain name space under
        &ldquo;in-addr-m.arpa&rdquo;. For an IPv4 address block 192.0.2.0/24,
        the corresponding AMR record name is constructed by reversing the IPv4
        prefix and appending ".in-addr-m.arpa". Example:<list style="empty">
            <t>IPv4 block: 192.0.2.0/24</t>

            <t>IPv6 mapping prefix: 2001:db8::/64</t>

            <t>The AMR record: 0.2.0.192.in-addr-m.arpa. IN AMR
            2001:db8::/64</t>
          </list></t>
      </section>

      <section title="AMR Encoding">
        <t>The encoding of the type is shown below&#65306;</t>

        <figure>
          <artwork align="center"><![CDATA[          
    +----------------------------------------+              
    |        Name (variable)                 |  
    +----------------------------------------+  
    |        Type (2 octets)                 |   
    +----------------------------------------+
    |        Class (2 octets)                | 
    +----------------------------------------+
    |        TTL (4 octets)                  | 
    +----------------------------------------+
    |        Data Length (2 octets)          | 
    +----------------------------------------+
    |        v4prefix-length (1 octet)       |
    +----------------------------------------+
    |        v6prefix-length (1 octet)       |
    +----------------------------------------+
    |        v6prefix (0...16 octets)        |
    +----------------------------------------+

            Figure 1: Format of AMR Record
]]></artwork>
        </figure>

        <t/>

        <t><list style="empty">
            <t>Name&mdash; the reverse IPv4 address, its format is IPv4
            address block.in-addr-m.arpa;</t>

            <t>Type&mdash; the type of the record&#65292;AMR;</t>

            <t>Class&mdash; indicating that the record is for the Internet
            environment;</t>

            <t>TTL&mdash;time-to-live in cache;</t>

            <t>Data length&mdash; length of the data section;</t>

            <t>v4prefix-length&mdash; length of the IPv4 address block;</t>

            <t>v6prefix-length&mdash; length of the IPv6 mapping prefix;</t>

            <t>v6prefix&mdash; IPv6 mapping prefix.</t>
          </list></t>
      </section>
    </section>

    <section title="Operation">
      <t>In a multi-domain IPv6-only network architecture, PE1 and PE2 are
      network edge devices with rule-based IPv4-IPv6 conversion capabilities,
      and their address mapping prefixes are denoted as Pref6. Each edge
      device also needs to be associated with one or more IPv4 address blocks,
      which are extracted from the local IPv4 routing table or address pool.
      IPv4 packets enter the multi-domain IPv6-only network via an ingress PE
      and exit via an egress PE. The mapping relationship between an IPv4
      address block and its corresponding IPv6 prefix is referred ro as
      a&nbsp;mapping rule, which will have at least the following data
      structure.<list style="empty">
          <t>IPv4 address block: Pref6(PE)</t>
        </list></t>

      <t><figure>
          <artwork align="center"><![CDATA[          
                        Global DNS System
                   |<---------------------->|
                   |                        |
                   |                        |
 +------------------+                      +-------------------+
 |                  |    2.publish AMR     |                   |
 |                  |--------------------->|                   |
 |                  |<---------------------|                   |
 |  Authoritative   |5.TTL expire, query   | Local DNS  Server | 
 |  DNS Server      | the latest record    |                   |
 |                  |                      |                   |
 |                  |                      |                   |
 |                  |--------------------->|                   |
 |                  |6.reply the lastest   |                   |
 |                  |  AMR                 |                   |
 +------------------+                      +-------------------+ 
                  ^                              ^|
                1.|                              ||
                r |                              ||
                e |                              ||
                g |                            3.||4.
                i |                            q ||r
                s |                            u ||e
                t |                            e ||p
                r |                            r ||l
                a |                            y ||y
                t |                              ||
                i |                              ||
                o |                              ||
                n |                              ||
                +-+------------------------------++-+
                | |                              || |
                | |   +-+        +-+        +-+  || |
 +----------+   | |  /AS1\      /AS2\      /AS3\ || |   +----------+
 |IPv4      |   | | |     |    |     |    |     ||V |   |IPv4      |
 |network N1|---+-PE1     P1--P2     P3--P4     PE2-+---|network N2|
 +----------+   |   |     |    |     |    |     |   |   +----------+
                |    \   /      \   /      \   /    |
                |     +-+        +-+        +-+     |
                |                                   |
                |  Multi-domain IPv6-only Network   |                         
                +-----------------------------------+
 
            Figure 2: The Option B cross-domain scenario
            
]]></artwork>
        </figure></t>

      <t>The AMR mechanism enables the distribution and retrieval of these
      mappings via DNS, as detailed below.</t>

      <section title="Mapping Relationship Registration">
        <t>PE1 router generate mappings between local IPv4 address blocks
        (served by their connected IPv4 networks) and their own IPv6 mapping
        prefixes (Pref6). Then, PE1 send these mappings to an authoritative
        DNS server, which stores them as AMR records in its database. The
        authoritative server validates the format of the mappings (e.g.,
        correct prefix lengths, valid IPv6 prefixes) before adding them to the
        appropriate zone file under&nbsp;in-addr-m.arpa.</t>
      </section>

      <section title="AMR Record Publication in Global DNS">
        <t>Authoritative DNS servers publish AMR records within their managed
        DNS zones, making them available for query by local DNS servers. AMR
        records are assigned a TTL value (e.g., 3600 seconds) to control cache
        freshness. Local DNS servers cache AMR records and refresh them by
        querying the authoritative server once the TTL expires, ensuring
        up-to-date mappings.</t>
      </section>

      <section title="Procedure for Ingress PE to Query IPv6 Mapping Prefix for a Specific IPv4 Address via DNS">
        <t>When Ingress PE receives an IPv4 packet, it queries the DNS to
        retrieve the corresponding IPv6 mapping prefix. The procedure is as
        follows:</t>

        <t><list style="numbers">
            <t>Extracts destination IPv4 address (e.g., 192.0.2.1).</t>

            <t>Query Construction: <t>Ingress PE constructs a DNS query using
            the reversed destination IPv4 address appended
            with&nbsp;.in-addr-m.arpa&nbsp;and specifies
            the&nbsp;AMR&nbsp;record type. For example, a destination IPv4
            address of 192.0.2.1 (within 192.0.2.0/24) results in the query
            name&nbsp;1.2.0.192.in-addr-m.arpa. IN AMR.</t></t>

            <t>Query Resolution: <t>
                <list style="letters">
                  <t>Checks local DNS cache for existing AMR record:<list
                      style="hanging">
                      <t hangText="i."> If valid cached record exists with
                      unexpired TTL:<list style="hanging">
                          <t hangText="&mdash;">Uses the cached IPv6 prefix
                          for packet conversion;</t>

                          <t hangText="&mdash;">Skips further DNS queries.</t>
                        </list></t>

                      <t hangText="ii.">If no valid cache entry exists:<list
                          style="hanging">
                          <t hangText="&mdash;">Proceeds to step 3b.</t>
                        </list></t>
                    </list></t>

                  <t>Queries configured local recursive resolver (if any):<list
                      style="hanging">
                      <t hangText="i.">Local resolver checks its cache and
                      zone data;</t>

                      <t hangText="ii.">If record exists in local
                      authoritative zones:<list style="hanging">
                          <t hangText="&mdash;">Returns AMR record with
                          TTL;</t>

                          <t hangText="&mdash;">PE updates local cache;</t>

                          <t hangText="&mdash;">Proceeds to packet
                          conversion.</t>
                        </list></t>

                      <t hangText="iii.">If no local record exists:<list
                          style="hanging">
                          <t hangText="&mdash;">Proceeds to step 3c</t>
                        </list></t>
                    </list></t>

                  <t>Initiates standard DNS resolution via recursive
                  lookup:<list style="hanging">
                      <t hangText="i.">Follows normal DNS resolution chain;</t>

                      <t hangText="ii.">Queries authoritative servers for
                      in-addr-m.arpa;</t>

                      <t hangText="iii.">Validates DNSSEC signatures if
                      present.</t>
                    </list></t>
                </list>
              </t></t>

            <t>Cache Refresh: <t>When the TTL of a cached AMR record expires,
            the local server re-queries the authoritative server to fetch the
            latest record, updating its cache accordingly.</t></t>
          </list></t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>The AMR mechanism introduces several security considerations:</t>

      <t>* Attackers could provide false mapping information. DNSSEC <xref
      target="RFC4033"/> MUST be used to authenticate AMR record.</t>

      <t>* Rate limiting SHOULD be implemented for AMR queries.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document defines a new Domain Name System (DNS) resource record
      type - Address Mapping Record (AMR) from the "DNS PARAMETERS"
      registry.</t>
    </section>

    <section title="Acknowledgements">
      <t>This comments and suggestions of the following are gratefully
      acknowledged:</t>

      <t>* TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.1034"?>

      <?rfc include="reference.RFC.1035"?>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.4026"?>

      <?rfc include="reference.RFC.4033"?>
    </references>

    <references title="Iormative References">
      <?rfc include="reference.RFC.6891"?>

      <?rfc include="reference.I-D.ietf-v6ops-framework-md-ipv6only-underlay"?>
    </references>
  </back>
</rfc>