Internet-Draft DNS64 flag for DNS RA Option August 2025
Ma & Xie Expires 2 March 2026 [Page]
Workgroup:
IPv6 Maintenance
Internet-Draft:
draft-ma-6man-ra-dns64-flag-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
C. Ma
China Telecom
C. Xie
China Telecom

Updates to DNS64 Functionality Advertisement for DNS RA Option

Abstract

This document defines a new flag in the DNS RA Option to advertise the DNS64 functionality. This extension enables automatic configuration of DNS64 resolution, improving deployability in IPv6 transition scenarios.

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 2 March 2026.

1. Introduction

DNS Extensions for Network Address Translation from IPv6 clients to IPv4 servers (DNS64)[RFC6147] is a widely deployed mechanism for IPv6-only networks requiring access to IPv4-only services. [I-D.ma-v6ops-5g-ipv6only]introduce the reasons for using RA to deliver DNS64 address configuration. This document defines a new flag in the DNS RA option[RFC8106] to communicate DNS64 server address to hosts.

1.1. Requirements Language

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[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. DNS64 Flag

Based on [RFC8106], this specification introduces a 'T' flag bit allocated in the leftmost bit of the Reserved field to signal the presence of DNS64 server addresses in the option payload. Figure 1 shows the format of the DNS64 option.

0                   1                   2                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |T|         Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Lifetime                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            DNS64 Server Address(es) (128-bit IPv6)            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 1:DNS64 RA Option format

Fields:

  • Type: 8-bit identifier: 25

  • Length: 8-bit unsigned integer.

  • Flag T: 1-bit integer. set to indicate DNS64 server addresses are in the option payload.

  • Lifetime: 32-bit unsigned integer.

  • DNS64 Server Address(es): One or more 128-bit IPv6 addresses of the DNS64.

3. Security Considerations

This memo does not introduce any new security problems. Considerations are described in Section 7 in [RFC8106]

4. IANA Considerations

This document requests allocation for the Flag T.

5. Acknowledgements

The comments and suggestions of the following are gratefully acknowledged:

6. References

6.1. Normative References

[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>.
[RFC4861]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <https://www.rfc-editor.org/info/rfc4861>.
[RFC6147]
Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, , <https://www.rfc-editor.org/info/rfc6147>.
[RFC8106]
Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, , <https://www.rfc-editor.org/info/rfc8106>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

6.2. Informative References

[I-D.ma-v6ops-5g-ipv6only]
Ma, C. and C. Xie, "Considerations of Gradual IPv6-only Deployment in 5G Mobile Networks", Work in Progress, Internet-Draft, draft-ma-v6ops-5g-ipv6only-00, , <https://datatracker.ietf.org/doc/html/draft-ma-v6ops-5g-ipv6only-00>.

Authors' Addresses

Chenhao Ma
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China