DNS-Based Address Mapping Record (AMR) for IPv4/IPv6 Mapping in IPv6-only Networks

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：¶

    +----------------------------------------+
    |        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.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:¶

   1. 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:¶

      —

      Proceeds to step 3b.¶

   2. 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.)¶

   3. 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:¶

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

9.1. Normative References

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