



DNSOP Working Group                                              G. Dong
Internet-Draft                                                    C. Xie
Intended status: Standards Track                           China Telecom
Expires: 23 November 2026                                    22 May 2026


    DNS-Based Address Mapping Record (AMR) for IPv4/IPv6 Mapping in
                           IPv6-only Networks
                   draft-dong-dnsop-dns-record-amr-01

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 23 November 2026.

Copyright Notice

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










Dong & Xie              Expires 23 November 2026                [Page 1]

Internet-Draft                     AMR                          May 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  AMR Record Format . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Record Name Construction  . . . . . . . . . . . . . . . .   3
     4.2.  AMR Encoding  . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Mapping Relationship Registration . . . . . . . . . . . .   7
     5.2.  AMR Record Publication in Global DNS  . . . . . . . . . .   7
     5.3.  Procedure for Ingress PE to Query IPv6 Mapping Prefix for a
           Specific IPv4 Address via DNS . . . . . . . . . . . . . .   7
     5.4.  Delegation and Management of in-addr-m.arpa . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Allocation of AMR Resource Record Type  . . . . . . . . .  10
     7.2.  Creation and Delegation of in-addr-m.arpa . . . . . . . .  10
     7.3.  DNS PARAMETERS Registry Update  . . . . . . . . . . . . .  10
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   [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.









Dong & Xie              Expires 23 November 2026                [Page 2]

Internet-Draft                     AMR                          May 2026


   This document defines a new Domain Name System (DNS) resource record
   type, called the Address Mapping Record (AMR).  AMR record
   stores the mappings between IPv4 address blocks and their
   corresponding IPv6 prefixes, enabling PE to query these mappings via
   standard DNS protocols.  AMR is applicable in IPv6-only networks
   [I-D.ietf-v6ops-framework-md-ipv6only-underlay].

2.  Conventions used in this document

   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 [RFC2119] .

3.  Terminology

   The following terms are defined in this draft:

   *  DNS: Domain Name System, defined in [RFC1034][RFC1035]

   *  PE: Provider Edge, defined in [RFC4026]

   *  Pref6: IPv6 Mapping Prefix, indicating edge devices for
      translating IPv4 packets in an IPv6-only network.


4.  AMR Record Format

4.1.  Record Name Construction

   AMR records use a special domain name space under “in-addr-m.arpa”.
   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:

      IPv4 block: 192.0.2.0/24

      IPv6 mapping prefix: 2001:db8::/64

      The AMR record: 0.2.0.192.in-addr-m.arpa.  IN AMR 2001:db8::/64

4.2.  AMR Encoding

   The encoding of the type is shown below：








Dong & Xie              Expires 23 November 2026                [Page 3]

Internet-Draft                     AMR                          May 2026


                  +----------------------------------------+
                  |        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


      Name— the reverse IPv4 address, its format is IPv4 address
      block.in-addr-m.arpa;

      Type— the type of the record，AMR;

      Class— indicating that the record is for the Internet environment;

      TTL—time-to-live in cache;

      Data length— length of the data section;

      v4prefix-length— length of the IPv4 address block;

      v6prefix-length— length of the IPv6 mapping prefix;

      v6prefix— IPv6 mapping prefix.

5.  Operation

   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



Dong & Xie              Expires 23 November 2026                [Page 4]

Internet-Draft                     AMR                          May 2026


   prefix is referred ro as a mapping rule, which will have at least the
   following data structure.

      IPv4 address block: Pref6(PE)















































Dong & Xie              Expires 23 November 2026                [Page 5]

Internet-Draft                     AMR                          May 2026


                           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

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




Dong & Xie              Expires 23 November 2026                [Page 6]

Internet-Draft                     AMR                          May 2026


5.1.  Mapping Relationship Registration

   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 in-addr-m.arpa.

5.2.  AMR Record Publication in Global DNS

   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.

5.3.  Procedure for Ingress PE to Query IPv6 Mapping Prefix for a
      Specific IPv4 Address via DNS

   When Ingress PE receives an IPv4 packet, it queries the DNS to
   retrieve the corresponding IPv6 mapping prefix.  The procedure is as
   follows:

   1.  Extracts destination IPv4 address (e.g., 192.0.2.1).

   2.  Query Construction:

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

   3.  Query Resolution:

       a.  Checks local DNS cache for existing AMR record:

           i.  If valid cached record exists with unexpired TTL:

              —  Uses the cached IPv6 prefix for packet conversion;

              —  Skips further DNS queries.

           ii.  If no valid cache entry exists:




Dong & Xie              Expires 23 November 2026                [Page 7]

Internet-Draft                     AMR                          May 2026


              —  Proceeds to step 3b.

       b.  Performs DNS longest-prefix match lookup for the destination
           IPv4 address using the following iterative procedure:

              Let the destination IPv4 address be A.B.C.D (four octets).

              For N from 4 down to 1:

              -  Construct a domain name using the least significant N
                 octets of the IPv4 address in reverse order, appended
                 with "in-addr-m.arpa".

                 Example for destination 192.0.2.1(octets 192, 0, 2, 1):

                    N=4: 1.2.0.192.in-addr-m.arpa

                    N=3: 2.0.192.in-addr-m.arpa

                    N=2: 0.192.in-addr-m.arpa

                    N=1: 192.in-addr-m.arpa

              -  Send a DNS query for type AMR for the constructed name.

                 If a non-empty AMR record is returned (NOERROR with at
                 least one answei), the associated IPv6 prefix is used
                 for packet conversion, and the procedure terminates.

                 If NxDOMAIN or NOERROR with zero answers is returned,
                 continue to the next smaller N.

              If no AMR record is found for any N, the destination IPv4
              address has no mapping, and the packet SHOULD be dropped
              or handled according to local policy (e.g., fallback to
              stateful translation.)

       c.  If the local resolver does not have the answer, it initiates
           standard DNS resolution via recursive lookup as follows:

           i.  Follows normal DNS resolution chain.

           ii.  Queries authoritative servers for in-addr-m.arpa.

           iii.  Validates DNSSEC signatures if present.

   4.  Cache Refresh:




Dong & Xie              Expires 23 November 2026                [Page 8]

Internet-Draft                     AMR                          May 2026


       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.

5.4.  Delegation and Management of in-addr-m.arpa

   The AMR mechanism relies on the reverse mapping domain "in-addr-
   m.arpa".  The delegation and management of this domain MUST follow a
   well-defined hierarchy.

   This document proposes that the delegation model for in-addr-m.arpa
   SHALL mirror that of in-addr.arpa:

   -  The "arpa" domain is managed by IANA.  IANA delegates the top-
      level "in-addr-m.arpa" zone.

   -  Delegations under "in-addr-m.arpa" SHALL correspond to the IPv4
      address allocation hierarchy.  Specifically, each Regional
      Internet Registry (RIR) is responsible for delegations under the
      subdomain corresponding to the /8 IPv4 address blocks it manages.
      For example, for the 192.0.0.0/8 block, the responsible RIR (e.g.,
      APNIC) manages delegations under 192.in-addr-m.arpa.

   -  RIRs MAY further delegate subdomains to their members (e.g., ISPs
      or end users) following existing reverse DNS delegation
      procedures, such as those documented in [RFC2317] for classless
      delegations.

   Note (Open Issue): As of this version of the draft, the authors have
   not yet formally consulted with the RIRs regarding the delegation and
   management of "in-addr-m.arpa".  The authors intend to initiate such
   discussions once the technical approach has received initial feedback
   from the DNSOP Working Group.

   If RIR coordination proves infeasible, AMR can still be deployed
   within a single administrative domain (e.g., an ISP's internal DNS)
   without global in-addr-m.arpa delegation.  This document describes
   the global delegation model as the preferred approach but does not
   preclude private/internal deployments.

6.  Security Considerations

   The AMR mechanism introduces several security considerations:

   * Attackers could provide false mapping information.  DNSSEC
   [RFC4033] MUST be used to authenticate AMR record.

   * Rate limiting SHOULD be implemented for AMR queries.



Dong & Xie              Expires 23 November 2026                [Page 9]

Internet-Draft                     AMR                          May 2026


7.  IANA Considerations

   This document defines a new DNS Resource Record type - Address
   Mapping Record (AMR) from the "DNS PARAMETERS" registry.

7.1.  Allocation of AMR Resource Record Type

   IANA is requested to allocate a new DNS Resource Record Type code for
   the Address Mapping Record (AMR) from the "Resource Record (RR)
   TYPEs" registry under the "Domain Name System (DNS) Parameters" group
   [IANA-DNS-PARAMETERS].

      Type: AMR

      Value: TBD (to be assigned by IANA)

      Meaning: Address Mapping Record

7.2.  Creation and Delegation of in-addr-m.arpa

   IANA is requested to create the reverse mapping zone "in-addr-m.arpa"
   under the "arpa" domain.  The delegation policies for this zone are
   to be defined in coordination with the Regional Internet Registries
   (RIRs) and will be documented in a separate specification or an
   updated version of this document.

   This may require registration of "in-addr-m.arpa" as a Special-
   Purpose Domain under the "Special-Use Domain Names" registry
   [RFC6761].  The authors will coordinate with IANA and the RIRs to
   determine the appropriate registration status prior to publication.

7.3.  DNS PARAMETERS Registry Update

   No other parameters are requested from the DNS PARAMETERS registry at
   this time.

8.  Acknowledgements

   This comments and suggestions of the following are gratefully
   acknowledged:

   * TBD

9.  References

9.1.  Normative References





Dong & Xie              Expires 23 November 2026               [Page 10]

Internet-Draft                     AMR                          May 2026


   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026,
              DOI 10.17487/RFC4026, March 2005,
              <https://www.rfc-editor.org/info/rfc4026>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

9.2.  Informative References

   [I-D.ietf-v6ops-framework-md-ipv6only-underlay]
              Xie, C., Ma, C., Li, X., Mishra, G. S., and T. Graf,
              "Framework for Multi-domain IPv6-only Underlay Network and
              IPv4-as-a-Service", Work in Progress, Internet-Draft,
              draft-ietf-v6ops-framework-md-ipv6only-underlay-22, 8 May
              2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
              v6ops-framework-md-ipv6only-underlay-22>.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/info/rfc6761>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/info/rfc6891>.

Authors' Addresses








Dong & Xie              Expires 23 November 2026               [Page 11]

Internet-Draft                     AMR                          May 2026


   Guozhen Dong
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: guozhen.dong@foxmail.com


   Chongfeng Xie
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: xiechf@chinatelecom.cn



































Dong & Xie              Expires 23 November 2026               [Page 12]
