[DNSOP] Re: [happy] Indicating ipv6only and deprecation via SVCB: draft-nygren-dnsop-ipv6only-indicator-00.txt
Erik Nygren <[email protected]> Tue, 7 Jul 2026 15:34:52 -0400
| Newsgroups | gmane.ietf.dnsop,gmane.ietf.v6ops |
|---|---|
| Message-ID | <CAKC-DJh3TSoWu=0bquLbnDnXn3Hgs5Vs8OpnFdkUFiz9nbOTOQ@mail.gmail.com> |
--===============5811298787013648047== Content-Type: multipart/alternative; boundary="000000000000ffdb1606560a7cf5" --000000000000ffdb1606560a7cf5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" =3D= =3D> 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=E2=80=AFPM 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=3D", > "info=3D", etc. "Deprecated" seems like too narrow a meaning here. > > --Ben > > On Mon, Jul 6, 2026 at 6:35=E2=80=AFPM 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 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 > 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 ha= s > 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=E2=80=AFPM > > 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-indicat= or > > > > > > Abstract: > > > > 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). > > > > 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] > --000000000000ffdb1606560a7cf5 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 Ben,</div><div><br></div><div><div style=3D"font-family:tahom= a,sans-serif" class=3D"gmail_default">I think you raise a good point here.= =C2=A0 I wonder if we could instead refactor this as a general=C2=A0</div><= div style=3D"font-family:tahoma,sans-serif" class=3D"gmail_default">SVCB wa= rning or status indicator draft (eg, a warn or status SvcParam with a type = code from a registry</div><div style=3D"font-family:tahoma,sans-serif" clas= s=3D"gmail_default">followed by a free-form string).=C2=A0 "Deprecatio= n" might be a warning type code.</div><div style=3D"font-family:tahoma= ,sans-serif" class=3D"gmail_default">This could then be useful for operatio= nal diagnostics of HAPPY when interacting with SVCB,</div><div style=3D"fon= t-family:tahoma,sans-serif" class=3D"gmail_default">and could potentially f= eed into some use-cases for=C2=A0draft-palet-happy-reporting-considerations= .</div><div style=3D"font-family:tahoma,sans-serif" class=3D"gmail_default"= ><br></div><div style=3D"font-family:tahoma,sans-serif" class=3D"gmail_defa= ult">We could potentially ditch the ipv6only SvcParam and you could get som= ething close enough</div><div style=3D"font-family:tahoma,sans-serif" class= =3D"gmail_default">by using a ServiceMode record with a TargetName that onl= y had an AAAA record.</div><div style=3D"font-family:tahoma,sans-serif" cla= ss=3D"gmail_default"><br></div><div style=3D"font-family:tahoma,sans-serif"= class=3D"gmail_default">The operational "how to use this" could = then split off into a separate v6ops draft,</div><div style=3D"font-family:= tahoma,sans-serif" class=3D"gmail_default">perhaps waiting for a time when = there was interest in doing this.</div><div style=3D"font-family:tahoma,san= s-serif" class=3D"gmail_default"><br></div><div style=3D"font-family:tahoma= ,sans-serif" class=3D"gmail_default">I think you highlight two useful reaso= ns why we might still want ipv6only.</div><div style=3D"font-family:tahoma,= sans-serif" class=3D"gmail_default">Some additional possible reasons:</div>= <div style=3D"font-family:tahoma,sans-serif" class=3D"gmail_default"><br></= div><div style=3D"font-family:tahoma,sans-serif" class=3D"gmail_default">Re= 2) " 2. IPv4-only clients can avoid waiting for the NODATA response" =3D=3D= > This is at least an RTT so isn't nothing?</div><div style=3D"font-= family:tahoma,sans-serif" class=3D"gmail_default">3) It would be nice if we= could retire or greatly reduce the number of "A" queries eventua= lly.=C2=A0 (I guess a simpler alternative would be for clients to only quer= y for them=C2=A0if they didn't get a AAAA response in some future HEvN = after some of us have retired.)</div><div style=3D"font-family:tahoma,sans-= serif" class=3D"gmail_default">4) Clients doing HE may have some number of = failure cases they are comfortable walking through.=C2=A0 If having a top-p= riority IPv6-only ServiceMode record triggers failures for IPv4-only client= s not willing to retry with the next lower priority record, then this might= be an operational blocker.=C2=A0 The ipv6only attribute would get them to = skip this entirely.=C2=A0</div><div style=3D"font-family:tahoma,sans-serif"= class=3D"gmail_default">5) Operationally being able to explicitly indicate= "this is IPv6-only on purpose" could help with monitoring and to= avoid errors.=C2=A0 (In the CDN provisioning interface for $dayjob we'= ve explicitly made it hard to provision IPv6-only to avoid people accidenta= lly doing that while trying to dual-stack.)</div><div style=3D"font-family:= tahoma,sans-serif" class=3D"gmail_default"><br></div><div style=3D"font-fam= ily:tahoma,sans-serif" class=3D"gmail_default">One thing from your list and= the others is that the clients which benefit the most from the "ipv6o= nly" SvcParam are ironically the IPv4-only clients that we want to dis= courage and try to get onto IPv6.</div><div style=3D"font-family:tahoma,san= s-serif" class=3D"gmail_default"><br></div><div style=3D"font-family:tahoma= ,sans-serif" class=3D"gmail_default">I'm not sure if any of these are s= trong enough reasons on their own?</div><div style=3D"font-family:tahoma,sa= ns-serif" class=3D"gmail_default"><br></div><div style=3D"font-family:tahom= a,sans-serif" class=3D"gmail_default">Best, Erik</div><div style=3D"font-fa= mily:tahoma,sans-serif" class=3D"gmail_default"><br></div><div style=3D"fon= t-family:tahoma,sans-serif" class=3D"gmail_default"><br></div><div style=3D= "font-family:tahoma,sans-serif" class=3D"gmail_default"><br></div><div styl= e=3D"font-family:tahoma,sans-serif" class=3D"gmail_default"><br></div><br><= /div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D= "ltr" class=3D"gmail_attr">On Tue, Jul 7, 2026 at 3:11=E2=80=AFPM Ben Schwa= rtz <<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<b= r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= ;border-left:1px solid rgb(204,204,204);padding-left:1ex">If I understand c= orrectly, the benefit of the "ipv6only" flag is:<br> <br> 1. Dual-stack clients can skip the "A" query, for efficiency.<br> 2. IPv4-only clients can avoid waiting for the NODATA response to the<br> A query before trying the next SVCB record.<br> <br> DNS queries are cheap enough that #1 doesn't seem very compelling.<br> (SVCB wastes a _lot_ of queries already.)=C2=A0 #2 seems like it could be<b= r> valuable in some situation, but the benefit is only to v4-only<br> clients.=C2=A0 I imagine that in this deployment scenario, those clients<br= > are not highly performance-sensitive.<br> <br> I do think the "deprecated" flag is interesting.=C2=A0 However, I= wonder if<br> it would be better as a collection of logging flags like "warning=3D&q= uot;,<br> "info=3D", etc.=C2=A0 "Deprecated" seems like too narro= w a meaning here.<br> <br> --Ben<br> <br> On Mon, Jul 6, 2026 at 6:35=E2=80=AFPM Erik Nygren <<a href=3D"mailto:er= ik%[email protected]" target=3D"_blank">[email protected]</a>> wrote:= <br> ><br> > I've published a -00 draft proposing two new SvcParams for "i= pv6only" and for "deprecated", along with some operational e= xamples for how they might be used together. Abstract: As the DNS is the pr= imary mechanism for translating<br> > <br> > I've published a -00 draft proposing two new SvcParams for "i= pv6only" and for "deprecated", along with some operational e= xamples for how they might be used together.<br> ><br> > Abstract:<br> ><br> >=C2=A0 =C2=A0 As the DNS is the primary mechanism for translating from = hostnames to<br> >=C2=A0 =C2=A0 IP addresses, it is a logical place to signal that endpoi= nts are<br> >=C2=A0 =C2=A0 IPv6-only.=C2=A0 It is thus also a logical place to signa= l that legacy<br> >=C2=A0 =C2=A0 endpoints supporting IPv4 are being deprecated.=C2=A0 Thi= s specification<br> >=C2=A0 =C2=A0 introduces two SvcParams for SVCB-compatible RR types tha= t signal<br> >=C2=A0 =C2=A0 IPv6-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 something we desperately need now/yet but as something we w= ill want in a few years and thus should standardize sooner so that the impl= ementations are there for when we need it.<br> ><br> > The "deprecated" SvcParam is more generally useful. I give s= ome other examples of how it might be used for other purposes as well (eg, = for deprecating an http/1.1-only Service Endpoint).<br> ><br> > 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.=C2=A0 This i= dea has been tossed around a number of times while we were authoring RFC 94= 60 / SVCB (and might have been in some early drafts and I even vaguely reca= ll talking about some precursors to this in sunset4 and in happy).<br> ><br> > Best, Erik<br> ><br> ><br> > ---------- Forwarded message ---------<br> > From: <<a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>><br> > Date: Mon, Jul 6, 2026 at 5:54=E2=80=AFPM<br> > Subject: New Version Notification for draft-nygren-dnsop-ipv6only-indi= cator-00.txt<br> > To: Erik Nygren <<a href=3D"mailto:erik%[email protected]" target= =3D"_blank">[email protected]</a>><br> ><br> ><br> > A new version of Internet-Draft draft-nygren-dnsop-ipv6only-indicator-= 00.txt<br> > has been successfully submitted by Erik Nygren and posted to the<br> > IETF repository.<br> ><br> > Name:=C2=A0 =C2=A0 =C2=A0draft-nygren-dnsop-ipv6only-indicator<br> > Revision: 00<br> > Title:=C2=A0 =C2=A0 Indicating IPv6-only SVCB Endpoints and IPv4 Depre= cation in the DNS<br> > Date:=C2=A0 =C2=A0 =C2=A02026-07-06<br> > Group:=C2=A0 =C2=A0 Individual Submission<br> > Pages:=C2=A0 =C2=A0 11<br> > URL:=C2=A0 =C2=A0 =C2=A0 <a href=3D"https://www.ietf.org/archive/id/dr= aft-nygren-dnsop-ipv6only-indicator-00.txt" rel=3D"noreferrer" target=3D"_b= lank">https://www.ietf.org/archive/id/draft-nygren-dnsop-ipv6only-indicator= -00.txt</a><br> > Status:=C2=A0 =C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-= nygren-dnsop-ipv6only-indicator/" rel=3D"noreferrer" target=3D"_blank">http= s://datatracker.ietf.org/doc/draft-nygren-dnsop-ipv6only-indicator/</a><br> > HTML:=C2=A0 =C2=A0 =C2=A0<a href=3D"https://www.ietf.org/archive/id/dr= aft-nygren-dnsop-ipv6only-indicator-00.html" rel=3D"noreferrer" target=3D"_= blank">https://www.ietf.org/archive/id/draft-nygren-dnsop-ipv6only-indicato= r-00.html</a><br> > HTMLized: <a href=3D"https://datatracker.ietf.org/doc/html/draft-nygre= n-dnsop-ipv6only-indicator" rel=3D"noreferrer" target=3D"_blank">https://da= tatracker.ietf.org/doc/html/draft-nygren-dnsop-ipv6only-indicator</a><br> ><br> ><br> > Abstract:<br> ><br> >=C2=A0 =C2=A0 As the DNS is the primary mechanism for translating from = hostnames to<br> >=C2=A0 =C2=A0 IP addresses, it is a logical place to signal that endpoi= nts are<br> >=C2=A0 =C2=A0 IPv6-only.=C2=A0 It is thus also a logical place to signa= l that legacy<br> >=C2=A0 =C2=A0 endpoints supporting IPv4 are being deprecated.=C2=A0 Thi= s specification<br> >=C2=A0 =C2=A0 introduces two SvcParams for SVCB-compatible RR types tha= t signal<br> >=C2=A0 =C2=A0 IPv6-only endpoints (ipv6only) as well as deprecated endp= oints<br> >=C2=A0 =C2=A0 (deprecated).<br> ><br> >=C2=A0 =C2=A0 TO BE REMOVED: This document is being collaborated on in = Github at:<br> >=C2=A0 =C2=A0 <a href=3D"https://github.com/enygren/draft-nygren-dnsop-= ipv6only-indicator" rel=3D"noreferrer" target=3D"_blank">https://github.com= /enygren/draft-nygren-dnsop-ipv6only-indicator</a><br> >=C2=A0 =C2=A0 (<a href=3D"https://github.com/enygren/draft-nygren-dnsop= -ipv6only-indicator" rel=3D"noreferrer" target=3D"_blank">https://github.co= m/enygren/draft-nygren-dnsop-ipv6only-indicator</a>).<br> >=C2=A0 =C2=A0 The most recent working version of the document, open iss= ues, etc.<br> >=C2=A0 =C2=A0 should all be available there.=C2=A0 The authors (gratefu= lly) accept pull<br> >=C2=A0 =C2=A0 requests.<br> ><br> ><br> ><br> > The IETF Secretariat<br> ><br> ><br> > _______________________________________________<br> > happy mailing list -- <a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a><br> > To unsubscribe send an email to <a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a><br> </blockquote></div> --000000000000ffdb1606560a7cf5-- --===============5811298787013648047== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============5811298787013648047==--