Internet-Draft AMR July 2025
Dong & Xie Expires 8 January 2026 [Page]
Workgroup:
DNSOP Working Group
Internet-Draft:
draft-dong-dnsop-dns-record-amr-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
G. Dong
China Telecom
C. Xie
China Telecom

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

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 8 January 2026.

Table of Contents

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.

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:

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:

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

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 prefix is referred ro as a mapping rule, which will have at least the following data structure.

                        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.

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. Queries configured local recursive resolver (if any):

      i.
      Local resolver checks its cache and zone data;
      ii.

      If record exists in local authoritative zones:

      Returns AMR record with TTL;
      PE updates local cache;
      Proceeds to packet conversion.
      iii.

      If no local record exists:

      Proceeds to step 3c
    3. Initiates standard DNS resolution via recursive lookup:

      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.

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.

7. IANA Considerations

This document defines a new Domain Name System (DNS) resource record type - Address Mapping Record (AMR) from the "DNS PARAMETERS" registry.

8. Acknowledgements

This comments and suggestions of the following are gratefully acknowledged:

* TBD

9. References

9.1. Normative References

[RFC1034]
Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, , <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035]
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc4033>.

9.2. Iormative References

[I-D.ietf-v6ops-framework-md-ipv6only-underlay]
Xie, C., Ma, C., Li, X., Mishra, G. S., and T. Graf, "Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service", Work in Progress, Internet-Draft, draft-ietf-v6ops-framework-md-ipv6only-underlay-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-framework-md-ipv6only-underlay-11>.
[RFC6891]
Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, , <https://www.rfc-editor.org/info/rfc6891>.

Authors' Addresses

Guozhen Dong
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China