AI, IPv6, and the future Internet at IETF 126

IETF 126 welcomed 1,230 on-site participants and 672 remote attendees, setting a new attendance record. The sessions I attended focused mainly on Working Group and Birds of a Feather (BoF) discussions covering IP addressing, DNS operations, and AI.

From the sessions I attended, consensus is gradually emerging across discussions in the IPv6 Maintenance (6MAN), Distributed Mobility Management (DMM), DNS Operations (DNSOP) Working Groups and the Internet Architecture Board (IAB) Open Meeting: IPv6 and DNS will play increasingly important roles in the AI era. IPv6 provides the addressing scale needed for large-scale AI deployments, while DNS remains essential for service discovery and connectivity.

IP addressing discussions

China Telecom presented DNS-Based Address Mapping Record (AMR) for IPv4/IPv6 Mapping in IPv6-only Networks. The proposal uses DNS records to carry static IPv4-to-IPv6 mapping information within IPv6-only networks. This approach aims to improve DNS64/NAT64 operations and reduce the need for hard-coded mappings.

Discussions at the Internet Architecture Board (IAB) Open Meeting focused on the long-term implications of IPv4 exhaustion. Participants broadly agreed that large-scale deployment of AI agents and distributed compute nodes will require traceable, globally unique addresses. The anticipated scale of these deployments exceeds the practical limits of IPv4, making IPv6 a fundamental requirement.

Several participants also noted that large-scale Network Adress Translation (NAT) and translation mechanisms disrupt end-to-end identity, complicate agent discovery and trusted communications, and create challenges for security auditing.

Work continued on Segment Routing over IPv6 (SRv6) and Compressed SRv6 (RFC 9800) for compute interconnect environments.

Key topics included low-latency IPv6 forwarding and In-situ Operations, Administration, and Maintenance (IOAM) telemetry for GPU clusters and distributed AI training systems.

DNS discussions

Most DNS-related discussions took place within the DNS Operations (DNSOP) Working Group.

Debate continued around proposals for DNS-based AI agent discovery. At IETF 125, a proposal suggested using the subdomain with Service Binding (SVCB) and TXT records to support intra-domain agent discovery.

Supporters argued that existing mechanisms, such as DNS Service Discovery (DNS-SD) and SVCB, could support lightweight agent discovery without creating new protocols.

However, many DNSOP participants suggested that DNS is not designed to carry complex descriptions of AI agent capabilities. Concerns included the lack of standardized semantic models, inappropriate use of TXT records, and the potential for increased query volumes.

Based on the DNSOP discussions I attended, the prevailing view was that DNS should not be used to transport complex capability metadata. Instead, DNS should provide only basic service endpoint information. More advanced agent discovery mechanisms will be developed through the Discovery of Agents, Workloads, and Named entities (DAWN) initiative.

AI and AI agents

AI and AI agents were prominent topics at IETF 126. Multiple workstreams focused on developing an interoperable Internet protocol framework for agent-to-agent communication.

The most significant development was the launch of the DAWN BoF, which is expected to progress towards formal Working Group status.

DAWN aims to create a decentralized, scalable, cross-domain framework for AI agent discovery. The approach can use DNS as an underlying transport mechanism while avoiding the need to embed complex semantic information within DNS itself. This addresses many of the concerns raised during DNSOP discussions.

The session concluded with sufficient support to continue the Working Group formation process, with a proposal expected to be submitted at IETF 127.

My main takeaways from IETF 126

A consistent theme across discussions on IP, DNS, and AI was that the Internet's existing architecture may need to evolve to support large-scale deployment of AI agents. Many participants suggested that AI could strengthen the case for IPv6, as IPv4 scarcity and increasingly complex NAT environments are poorly suited to trusted, end-to-end communication between agents.

There was also broad agreement that DNS should remain focused on naming and service discovery, rather than becoming a repository for detailed AI capability information. Work on agent discovery is likely to progress through the proposed DAWN Working Group, while researchers and operators across the IETF are beginning to examine how AI-generated traffic could change DNS usage patterns and affect infrastructure stability.

My interpretation of discussions across several Working Groups and meetings is that a four-layer model for an AI-enabled Internet could emerge:

1. IPv6 for addressing and connectivity
2. DNS for naming and service discovery
3. DAWN for agent and workload discovery
4. Agent Communication Protocols ( agentproto ) for agent communication and interoperability

This remains an early-stage vision rather than an agreed architecture, but it illustrates how participants are beginning to think about the protocol foundations needed to support an Internet increasingly populated by AI agents.

What does this mean for the APNIC community?

The discussions at IETF 126 offer an early view of issues that could become increasingly important for the APNIC community.

The relationship between AI agents and IP addressing is only beginning to be explored, but the implications are potentially significant. Issues such as identity, traceability, addressing, and security align closely with APNIC's role in supporting Internet number resource management, routing security, and the ongoing development of Internet infrastructure. Likewise, the potential impact of machine-generated traffic on DNS infrastructure may create new opportunities for research, measurement, and engagement with the Asia Pacific technical community.

Anlei Hu is the Chief Scientist of China Internet Network Information Center (CNNIC) and an APNIC Executive Council (EC) member.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.