[DNSOP] Re: Indicating ipv6only and deprecation via SVCB: draft-nygren-dnsop-ipv6only-indicator-00.txt
Erik Nygren <[email protected]> Tue, 7 Jul 2026 12:14:08 -0400
| Newsgroups | gmane.ietf.dnsop,gmane.ietf.v6ops |
|---|---|
| Message-ID | <CAKC-DJgvXSAxCm8oAFq6sWD-K8X=A2TdE_HSHSDteo20Gi1AHA@mail.gmail.com> |
--===============3451322691744028421== Content-Type: multipart/alternative; boundary="000000000000040978065607af22" --000000000000040978065607af22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan, thanks for the feedback. And also thank you Paul for relaying Daniel Stenberg's similar feedback. I agree this is a legitimate criticism. In the current world of Happy Eyeballs and where ideally most content is dual-stacked it is unclear that there's enough value for deploying this. The absence of the DNS "A" record should be good enough for indicating IPv6-only, and outside of the "web" world I'm aware already of cases in closed environments for production services with only AAAA records. One use-case where SVCB may help beyond Happy Eyeballs are for cases where clients are being forced through SVCB/HTTPS RRs (with no fallback A/AAAA records on the hostname) and where a service wants to use different infrastructure with different capabilities for IPv6-only vs legacy dualstack support. The other use-case is for signalling planned deprecation for IPv4 support -- this would likely be most interesting in combination with HAPPY reporting capabilities. This DNS-based approach is a counterpoint to doing it in-band (eg, in HTTP response headers as proposed in https://datatracker.ietf.org/doc/html/draft-martin-retry-over-ipv6-02) I'm very much willing to accept that we just aren't ready yet for draft-nygren-dnsop-ipv6only-indicator (and perhaps with Happy Eyeballs we never will be and perhaps there are other better and simpler ways to achieve the same goals). If people have compelling arguments for why we will want this soon, that would be valuable. If not, even as a (eventually expired) draft this can potentially serve as a "here's how you might do this in SVCB if you wanted to signal it in the DNS" since I'm sure this idea will resurface every few years. Best, Erik On Mon, Jul 6, 2026 at 11:02=E2=80=AFPM Jan Schaumann <jschauma@netmeister.= org> wrote: > Erik Nygren <[email protected]> wrote: > > > As the DNS is the primary mechanism for translating from hostnames t= o > > 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 ar= e > there > > for when we need it. > > I have to admit that my experience so far with the > adoption of SVCB and HTTPS records makes me wonder > whether this will be a practically useful approach. > > Right now, browsers[1] are racing all three lookups > (HTTPS, A, and AAAA), and any findings from HTTPS > records are, if supported or implemented by browsers > at all, advisory at best. > > From a browser (or happy eyeballs) perspective, that > makes sense: waiting for the HTTPS result before then > having to possibly do another two sequential lookups > leads to a bad user experience. > > But that also means that the "ipv6only" param would > not be particularly useful in practice so long as > browsers still race the A and AAAA lookups. I > anticipate browsers will continue to do that for as > long as IPv4 and IPv6 records are both widely > used[2]. > > > As for the "deprecated" param, I also don't quite know > what I am to do with it when I observe it, given that > I "SHOULD NOT provide special treatment". > > I fear that the idea behind the proposal ("make it > easier for people to migrate off IPv4 and to > IPv6-only") is a solution in search of a problem: I'm > not convinced the technical ability to migrate is > hampered by the lack of a method to signal to clients > your intention; what's missing is the intention to > migrate. > > > As an entirely naive alternative, I would expect an > IPv6-only service to be one that has only AAAA records > (and includes ipv6hint params, but no ipv4hint params > in any SVCB records, which browsers may or may not > race at the same time). > > Perhaps it would be useful to include in the draft a > brief description why that is insufficient and whether > the anticipation is that browsers will (eventually) > _not_ race HTTPS and A/AAAA lookups but _only_ use > HTTPS lookups (or use those as blocking prior to any > A/AAAA lookups). > > Sorry, this got longer than I initially set out to. > > -Jan > > [1] And it really is browsers we have to care about > here, since those are effectively setting much of the > direction of the Web. > > [2] Which, in turn, I anticipate to remain the case > throughout the rest of my lifetime, at least. > --000000000000040978065607af22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:tahoma,s= ans-serif">Hi Jan, thanks for the feedback.=C2=A0 And also thank you Paul f= or relaying Daniel Stenberg's similar feedback.</div><div class=3D"gmai= l_default" style=3D"font-family:tahoma,sans-serif"><br></div><div class=3D"= gmail_default" style=3D"font-family:tahoma,sans-serif">I agree this is a le= gitimate criticism.=C2=A0 In the current world of Happy Eyeballs and where = ideally most content is dual-stacked it is unclear that there's enough = value for deploying this.=C2=A0 The absence of the DNS "A" record= should be good enough for indicating IPv6-only, and outside of the "w= eb" world I'm aware already of cases in closed environments for pr= oduction services with only AAAA records.</div><div class=3D"gmail_default"= style=3D"font-family:tahoma,sans-serif"><br></div><div class=3D"gmail_defa= ult" style=3D"font-family:tahoma,sans-serif">One use-case where SVCB may he= lp beyond Happy Eyeballs are for cases where clients are being forced throu= gh SVCB/HTTPS RRs (with no fallback A/AAAA records on the hostname) and whe= re a service wants to use different infrastructure with different capabilit= ies for IPv6-only vs legacy dualstack support.=C2=A0 The other use-case is = for signalling planned deprecation for IPv4 support -- this would likely be= most interesting in combination with HAPPY reporting capabilities.</div><d= iv class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><br></di= v><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">This= DNS-based approach is a counterpoint to doing it in-band (eg, in HTTP resp= onse headers as proposed in <a href=3D"https://datatracker.ietf.org/doc/htm= l/draft-martin-retry-over-ipv6-02">https://datatracker.ietf.org/doc/html/dr= aft-martin-retry-over-ipv6-02</a>)=C2=A0</div><div class=3D"gmail_default" = style=3D"font-family:tahoma,sans-serif"><br></div><div class=3D"gmail_defau= lt" style=3D"font-family:tahoma,sans-serif">I'm very much willing to ac= cept that we just aren't ready yet for=C2=A0draft-nygren-dnsop-ipv6only= -indicator (and perhaps with Happy Eyeballs we never will be and perhaps th= ere are other better and simpler ways to achieve the same goals). If people= have compelling arguments for why we will want this soon, that would be va= luable. If not, even as a (eventually expired) draft this can potentially s= erve as a "here's how you might do this in SVCB if you wanted to s= ignal it in the DNS" since I'm sure this idea will resurface every= few years.</div><div class=3D"gmail_default" style=3D"font-family:tahoma,s= ans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:taho= ma,sans-serif">Best, Erik</div><div class=3D"gmail_default" style=3D"font-f= amily:tahoma,sans-serif"><br></div><div class=3D"gmail_default" style=3D"fo= nt-family:tahoma,sans-serif"><br></div><div class=3D"gmail_default" style= =3D"font-family:tahoma,sans-serif"><br></div></div><br><div class=3D"gmail_= quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, = Jul 6, 2026 at 11:02=E2=80=AFPM Jan Schaumann <<a href=3D"mailto:jschaum= [email protected]">[email protected]</a>> wrote:<br></div><blockquo= te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = solid rgb(204,204,204);padding-left:1ex">Erik Nygren <<a href=3D"mailto:= erik%[email protected]" target=3D"_blank">[email protected]</a>> wrot= e:<br> <br> > =C2=A0 =C2=A0As the DNS is the primary mechanism for translating from = hostnames to<br> > =C2=A0 =C2=A0IP addresses, it is a logical place to signal that endpoi= nts are<br> > =C2=A0 =C2=A0IPv6-only.=C2=A0 It is thus also a logical place to signa= l that legacy<br> > =C2=A0 =C2=A0endpoints supporting IPv4 are being deprecated.=C2=A0 Thi= s specification<br> > =C2=A0 =C2=A0introduces two SvcParams for SVCB-compatible RR types tha= t signal<br> > =C2=A0 =C2=A0IPv6-only endpoints (ipv6only) as well as deprecated endp= oints<br> > =C2=A0 =C2=A0(deprecated).<br> > <br> > The "ipv6only" SvcParam touches on V6OPS and HAPPY.=C2=A0 I = see this not as<br> > something we desperately need now/yet but as something we will want in= a few<br> > years and thus should standardize sooner so that the implementations a= re there<br> > for when we need it.<br> <br> I have to admit that my experience so far with the<br> adoption of SVCB and HTTPS records makes me wonder<br> whether this will be a practically useful approach.<br> <br> Right now, browsers[1] are racing all three lookups<br> (HTTPS, A, and AAAA), and any findings from HTTPS<br> records are, if supported or implemented by browsers<br> at all, advisory at best.<br> <br> >From a browser (or happy eyeballs) perspective, that<br> makes sense: waiting for the HTTPS result before then<br> having to possibly do another two sequential lookups<br> leads to a bad user experience.<br> <br> But that also means that the "ipv6only" param would<br> not be particularly useful in practice so long as<br> browsers still race the A and AAAA lookups.=C2=A0 I<br> anticipate browsers will continue to do that for as<br> long as IPv4 and IPv6 records are both widely<br> used[2].<br> <br> <br> As for the "deprecated" param, I also don't quite know<br> what I am to do with it when I observe it, given that<br> I "SHOULD NOT provide special treatment".<br> <br> I fear that the idea behind the proposal ("make it<br> easier for people to migrate off IPv4 and to<br> IPv6-only") is a solution in search of a problem: I'm<br> not convinced the technical ability to migrate is<br> hampered by the lack of a method to signal to clients<br> your intention; what's missing is the intention to<br> migrate.<br> <br> <br> As an entirely naive alternative, I would expect an<br> IPv6-only service to be one that has only AAAA records<br> (and includes ipv6hint params, but no ipv4hint params<br> in any SVCB records, which browsers may or may not<br> race at the same time).<br> <br> Perhaps it would be useful to include in the draft a<br> brief description why that is insufficient and whether<br> the anticipation is that browsers will (eventually)<br> _not_ race HTTPS and A/AAAA lookups but _only_ use<br> HTTPS lookups (or use those as blocking prior to any<br> A/AAAA lookups).<br> <br> Sorry, this got longer than I initially set out to.<br> <br> -Jan<br> <br> [1] And it really is browsers we have to care about<br> here, since those are effectively setting much of the<br> direction of the Web.<br> <br> [2] Which, in turn, I anticipate to remain the case<br> throughout the rest of my lifetime, at least.<br> </blockquote></div> --000000000000040978065607af22-- --===============3451322691744028421== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============3451322691744028421==--