Hi Ben, I think you raise a good point here. I wonder if we could instead refactor this as a general SVCB warning or status indicator draft (eg, a warn or status SvcParam with a type code from a registry followed by a free-form string). "Deprecation" might be a warning type code. This could then be useful for operational diagnostics of HAPPY when interacting with SVCB, and could potentially feed into some use-cases for draft-palet-happy-reporting-considerations.
We could potentially ditch the ipv6only SvcParam and you could get something close enough by using a ServiceMode record with a TargetName that only had an AAAA record. The operational "how to use this" could then split off into a separate v6ops draft, perhaps waiting for a time when there was interest in doing this. I think you highlight two useful reasons why we might still want ipv6only. Some additional possible reasons: Re 2) " 2. IPv4-only clients can avoid waiting for the NODATA response" ==> This is at least an RTT so isn't nothing? 3) It would be nice if we could retire or greatly reduce the number of "A" queries eventually. (I guess a simpler alternative would be for clients to only query for them if they didn't get a AAAA response in some future HEvN after some of us have retired.) 4) Clients doing HE may have some number of failure cases they are comfortable walking through. If having a top-priority IPv6-only ServiceMode record triggers failures for IPv4-only clients not willing to retry with the next lower priority record, then this might be an operational blocker. The ipv6only attribute would get them to skip this entirely. 5) Operationally being able to explicitly indicate "this is IPv6-only on purpose" could help with monitoring and to avoid errors. (In the CDN provisioning interface for $dayjob we've explicitly made it hard to provision IPv6-only to avoid people accidentally doing that while trying to dual-stack.) One thing from your list and the others is that the clients which benefit the most from the "ipv6only" SvcParam are ironically the IPv4-only clients that we want to discourage and try to get onto IPv6. I'm not sure if any of these are strong enough reasons on their own? Best, Erik On Tue, Jul 7, 2026 at 3:11 PM Ben Schwartz <[email protected]> wrote: > 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] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
