I think this draft and draft-martin-retry-over-ipv6 are trying to achieve these goals:
1) Make clients aware of the (imminent) IPv4 deprecation 2) Avoid that those clients still do IPv4 calls on a dual stack network. for 1) so that IPv4-only client maintainers understand why the service is about to disappear, or has disappeared (so they can take action by either enabling IPv6 or notifying the service maintainer to re-enable IPv4 quickly). for 2) so that the service, monitoring its connections, knows that those dual stack clients behave like if A does not exist (so the logs only show the problematic clients with their IPv4(-only) connections). Even with 99% of connections on IPv6, you still do not want to deprecate IPv4. You will want something close to 99.9% or better. No large service wants to loose 1% of their customers, and with dual stack clients muddying the water, it is very hard to pull the plug. Franck ----- Original Message ----- From: "Ben Schwartz" <[email protected]> To: "Erik Nygren" <[email protected]> Cc: "dnsop WG" <[email protected]>, "[email protected] list" <[email protected]>, "happy" <[email protected]> Sent: Tuesday, July 7, 2026 12:10:48 PM Subject: [v6ops] Re: [happy] Indicating ipv6only and deprecation via SVCB: draft-nygren-dnsop-ipv6only-indicator-00.txt If I understand correctly, the benefit of the "ipv6only" flag is: 1. Dual-stack clients can skip the "A" query, for efficiency. 2. IPv4-only clients can avoid waiting for the NODATA response to the A query before trying the next SVCB record. DNS queries are cheap enough that #1 doesn't seem very compelling. (SVCB wastes a _lot_ of queries already.) #2 seems like it could be valuable in some situation, but the benefit is only to v4-only clients. I imagine that in this deployment scenario, those clients are not highly performance-sensitive. I do think the "deprecated" flag is interesting. However, I wonder if it would be better as a collection of logging flags like "warning=", "info=", etc. "Deprecated" seems like too narrow a meaning here. --Ben On Mon, Jul 6, 2026 at 6:35 PM Erik Nygren <[email protected]> wrote: > > I've published a -00 draft proposing two new SvcParams for "ipv6only" and for > "deprecated", along with some operational examples for how they might be used > together. Abstract: As the DNS is the primary mechanism for translating > > I've published a -00 draft proposing two new SvcParams for "ipv6only" and for > "deprecated", along with some operational examples for how they might be used > together. > > Abstract: > > As the DNS is the primary mechanism for translating from hostnames to > IP addresses, it is a logical place to signal that endpoints are > IPv6-only. It is thus also a logical place to signal that legacy > endpoints supporting IPv4 are being deprecated. This specification > introduces two SvcParams for SVCB-compatible RR types that signal > IPv6-only endpoints (ipv6only) as well as deprecated endpoints > (deprecated). > > The "ipv6only" SvcParam touches on V6OPS and HAPPY. I see this not as > something we desperately need now/yet but as something we will want in a few > years and thus should standardize sooner so that the implementations are > there for when we need it. > > The "deprecated" SvcParam is more generally useful. I give some other > examples of how it might be used for other purposes as well (eg, for > deprecating an http/1.1-only Service Endpoint). > > I'm still the only author on this, and am happy to talk to people in Vienna > if there others interested in joining as co-authors. This idea has been > tossed around a number of times while we were authoring RFC 9460 / SVCB (and > might have been in some early drafts and I even vaguely recall talking about > some precursors to this in sunset4 and in happy). > > Best, Erik > > > ---------- Forwarded message --------- > From: <[email protected]> > Date: Mon, Jul 6, 2026 at 5:54 PM > Subject: New Version Notification for > draft-nygren-dnsop-ipv6only-indicator-00.txt > To: Erik Nygren <[email protected]> > > > A new version of Internet-Draft draft-nygren-dnsop-ipv6only-indicator-00.txt > has been successfully submitted by Erik Nygren and posted to the > IETF repository. > > Name: draft-nygren-dnsop-ipv6only-indicator > Revision: 00 > Title: Indicating IPv6-only SVCB Endpoints and IPv4 Deprecation in the DNS > Date: 2026-07-06 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/archive/id/draft-nygren-dnsop-ipv6only-indicator-00.txt > Status: > https://datatracker.ietf.org/doc/draft-nygren-dnsop-ipv6only-indicator/ > HTML: > https://www.ietf.org/archive/id/draft-nygren-dnsop-ipv6only-indicator-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-ipv6only-indicator > > > Abstract: > > As the DNS is the primary mechanism for translating from hostnames to > IP addresses, it is a logical place to signal that endpoints are > IPv6-only. It is thus also a logical place to signal that legacy > endpoints supporting IPv4 are being deprecated. This specification > introduces two SvcParams for SVCB-compatible RR types that signal > IPv6-only endpoints (ipv6only) as well as deprecated endpoints > (deprecated). > > TO BE REMOVED: This document is being collaborated on in Github at: > https://github.com/enygren/draft-nygren-dnsop-ipv6only-indicator > (https://github.com/enygren/draft-nygren-dnsop-ipv6only-indicator). > The most recent working version of the document, open issues, etc. > should all be available there. The authors (gratefully) accept pull > requests. > > > > The IETF Secretariat > > > _______________________________________________ > happy mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ v6ops mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
