IETF 103 to debate DNS privacy, TLS and IPv6 drafts

At IETF 103 in Bangkok, the working group sessions begin on Monday with a packed four day schedule, and the Internet Society's Internet Technology Team has published a preview of the topics that matter for DNS privacy, transport encryption and the next generation of internet addressing. The IETF, or Internet Engineering Task Force, is the open standards body where engineers agree on the technical rules that make the internet work. Because only four days have been allocated this time, Monday's agenda covers several groups at once, and the organisers note that people who cannot attend in person can still participate remotely.

Monday morning starts with the IPv6 Operations working group, known as v6ops, at 09.00 local time (UTC+7). Since its last meeting, the group has published four RFCs, including Happy Eyeballs v2, which helps devices choose between IPv6 and IPv4 connections more smoothly. The session will open with a presentation on CERNET2, an IPv6 only research and education network in China. Four drafts are then on the table, three of them new. One, titled IPv6-Ready DNS/DNSSEC Infrastructure, recommends how to deploy DNS64, a technique that lets IPv6 only devices reach IPv4 only services by synthesising IPv6 addresses, because in some circumstances this modification of DNS records can break DNSSEC, the security layer that signs DNS data. Another draft, IPv6 Address Assignment to End-Sites, replaces RFC 6177 and takes best current operational practice from RIPE-690, reiterating that the assignment policy and guidelines belong to the regional internet registry community. A third draft, Pros and Cons of IPv6 Transition Technologies for IPv4aaS, compares different use case scenarios for the five most prominent IPv4 as a service transition technologies. The fourth, NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks, is an updated draft covering applications or devices that use literal IPv4 addresses, non-IPv6 compliant APIs, or IPv4 only hosts on an IPv6 only network.

At the same time, the Routing Over Low power and Lossy networks working group, or roll, will discuss an update to the ROLL-BIER design that extends RPL, the routing protocol for low power and lossy networks, to support Bit Index Explicit Replication (BIER) in environments with limited and lossy updates. Seven other drafts all related to RPL enhancements are also scheduled. Later in the morning at 11.20 local time, the Crypto Forum (cfrg) holds its session. The group has not yet published an agenda, but its currently active drafts cover public key exchange, the transition from classical to post-quantum cryptography, randomness improvements for security protocols, re-keying mechanisms for symmetric keys, and hash based signatures.

After lunch, two sessions run in parallel at 13.50. The Transport Layer Security (TLS) working group has the first of its two sessions, with the second on Wednesday afternoon. Among the important drafts are the proposed DTLS 1.3 specification and Connection Identifiers for DTLS, a mechanism designed to avoid the need for additional handshaking when a device's network address changes due to NAT rebinding. The group will also consider a proposal to deprecate TLS 1.0 and 1.1 because those older versions lack support for current and recommended cipher suites. Other drafts cover TLS authentication using ETSI TS 103 097 and IEEE 1609.2 certificates, a TLS 1.3 extension that allows a server to authenticate with a certificate while also providing a pre-shared key (PSK) as an input, and universal PSKs for TLS that use an extra key derivation step so the same secret can be reused for all TLS 1.3 key derivation function hashes. A revised working group charter has also been proposed. At the same time, the Domain Name System Operations (dnsop) working group has two drafts of particular interest: one outlines how to run a root server instance on the same machine as a recursive resolver to reduce the time it takes to get an answer, and another specifies a way for resolvers to tell clients which DNS over HTTPS (DoH) servers are associated with them. DoH is the method of sending DNS queries through encrypted web connections, and this discovery mechanism would make it easier for devices to find a resolver's encrypted endpoint automatically.

The final session of the day belongs to the IPv6 over Networks of Resource-constrained Nodes working group, or 6lo, at 16.10. Drafts on the agenda include an update to RFC 6775 to support registration extensions that simplify operations in 6LoWPAN routers, a technology that lets small battery powered devices use IPv6 over low power wireless networks. Another draft updates Address Protected Neighbor Discovery for Low-power and Lossy Networks. A third updates RFC 4944 with a simple protocol to recover packet fragments over a mesh network, and the group will prepare the IPv6 Backbone Router draft for a Working Group Last Call. The session ends with a performance report on fragment forwarding and recovery.

Taken together, Monday's agenda shows how the IETF is working on the invisible plumbing that decides whether a DNS query is private, whether a connection uses modern encryption, and whether networks can keep running as IPv4 addresses run out. The DNSOP discussion on DoH discovery is especially relevant to ordinary users, because if resolvers can advertise their encrypted endpoints automatically, more people will get DNS privacy without having to configure technical settings by hand. Deprecating TLS 1.0 and 1.1 pushes the web away from old, weak encryption, while the IPv6 transition work helps operators plan for networks that no longer depend on scarce IPv4 space. For readers who want to reduce what their own resolver can see or change, using a private, encrypted DNS service such as AEU DNS lets you send your queries over HTTPS or TLS and review the service's published privacy policies for yourself. The standards are still being debated in Bangkok, but the direction is clear: more encryption, more IPv6, and more operational guidance for a safer internet.