[happy] Re: Indicating ipv6only and deprecation via SVCB: draft-nygren-dnsop-ipv6only-indicator-00.txt

[Erik Nygren <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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: <[e-mail]>
> > Date: Mon, Jul 6, 2026 at 5:54 PM
> > Subject: New Version Notification for
> draft-nygren-dnsop-ipv6only-indicator-00.txt
> > To: Erik Nygren <[e-mail]>
> >
> >
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>