@meetecho our slides clicker isn't working (clicker itself is on, but doesn't seem to be received when slides control is passed to the clicker). We'll click manually for now, but FYI
", "time": "2026-07-20T12:10:59.000Z"}, {"author": "Lorenzo Miniero", "text": "Were the slides passed to the clicker? I see Tommy controlling them now
", "time": "2026-07-20T12:11:35.000Z"}, {"author": "Eric Kinnear", "text": "They were previously, we passed it to Tommy's phone for this talk since the clicker wasn't working
", "time": "2026-07-20T12:12:06.000Z"}, {"author": "Tim Chown", "text": "have also emailed ietf-support
", "time": "2026-07-20T12:12:18.000Z"}, {"author": "Benjamin Schwartz", "text": "I assume \"synthesize IPv4\" here means \"synthesize IPv6 from IPv4\"
", "time": "2026-07-20T12:13:12.000Z"}, {"author": "Erik Nygren", "text": "On the DNS front, there are lots of cans of worms if we go down that route. For example, current \"deprefer IPv6 if slow\" is problematic since things like lossy UDP and slow individual authorities may make it hard to derive whether an IPv4 or IPv6 recursive is better based simply on query response times.
", "time": "2026-07-20T12:34:58.000Z"}, {"author": "Benjamin Schwartz", "text": "@Lorenzo Colitti There is already some normative dependence on whether the resolution used a secure transport in RFC 9460, which is inherited here.
", "time": "2026-07-20T12:36:14.000Z"}, {"author": "Benjamin Schwartz", "text": "https://datatracker.ietf.org/doc/html/rfc9460#section-3.1-1
", "time": "2026-07-20T12:37:05.000Z"}, {"author": "Erik Nygren", "text": "One thing the current draft does conflate (and we need to improve on) is the authenticity of DNS responses (eg, from DNSSEC with a \"this was validated\" flag) and if an encrypted transport was used (which provides confidentiality from stub to recursive).
", "time": "2026-07-20T12:37:23.000Z"}, {"author": "Benjamin Schwartz", "text": "\n", "time": "2026-07-20T12:37:25.000Z"}, {"author": "Eric Kinnear", "text": "If DNS responses are cryptographically protected (e.g., using DNSSEC or TLS\u00a0[DoT]\u00a0[DoH]) and SVCB resolution fails due to an authentication error, SERVFAIL response, transport error, or timeout, the client\u00a0SHOULD\u00a0abandon its attempt to reach the service, even if the client is SVCB-optional.
\n
@Andrew, if you want to send your comment in the chat as well, folks can respond here
", "time": "2026-07-20T12:38:47.000Z"}, {"author": "Erik Nygren", "text": "Any intent for a queue/discussion on this, or just the presentation?
", "time": "2026-07-20T12:39:06.000Z"}, {"author": "Eric Kinnear", "text": "Speedy discussion, then the whole week of meals for extended discussion :)
", "time": "2026-07-20T12:39:24.000Z"}, {"author": "Benjamin Schwartz", "text": "Slide 5: This description only applies if every request checks if DNS is fresh, and blocks if it is not. But this only applies at connection establishment time, and no one should be establishing a new connection to the same domain every second.
", "time": "2026-07-20T12:41:22.000Z"}, {"author": "Erik Nygren", "text": "Privacy example: cloud providers reuse IPv4 between tenants on the order of minutes. (eg, AWS reuses after ~30 minutes per one study I found.) So you may be sending data to the wrong place and even if the handshake fails it is still a security exposure and privacy risk.
\nOperational example: operators need to be able to drain servers and server clusters. Just because you can connect successfully doesn't mean that the operator won't shut down the server or server cluster right after you connect. (Or that you may be getting Layer 7 errors due to the maintenance even if connects succeed.) This is not a concern on the order of seconds (or N% above TTL), but is a real problem if extending TTLs for hours past failure. At the order of days, it also makes it really hard for operators to recover from \"oops\" style mistakes, or handle cases like switching between providers/operators. (eg, someone switching between CDNs may no longer have proper configuration on their old one but the cert might still work for some time)
\nAnd to Ben: yes, having a SvcParam to opt-in addresses lots of these concerns.
", "time": "2026-07-20T12:50:49.000Z"}, {"author": "Benjamin Schwartz", "text": "The biggest annoyance in my experience is \"traffic on this old IP hasn't gone to zero yet; are we sure it's safe to turn off?\" In general, it would help a lot if something in the requests said \"this client will failover gracefully to another option if you shut this server off\".
", "time": "2026-07-20T12:53:00.000Z"}, {"author": "Tim Chown", "text": "we'll take questions at the end of the deck
", "time": "2026-07-20T12:56:41.000Z"}, {"author": "Erik Nygren", "text": "It's not just performance -- it's also the impact on the network (eg, for gettinf traffic off of NAT64 infrastrucutre) even if the connection is short, so please don't drop the IPv6 preference.
", "time": "2026-07-20T12:57:23.000Z"}, {"author": "Mike Blanche", "text": "+1 to Ben, there's enough problems already with ignoring TTLs, so making it clear somehow that \"I've ignored your TTL but I know what I'm doing\" would be helpful
", "time": "2026-07-20T12:58:56.000Z"}, {"author": "Benjamin Schwartz", "text": "+1 Lorenzo. Plain old \"retry\" turns out to be worth a lot.
", "time": "2026-07-20T13:02:42.000Z"}, {"author": "Mirja K\u00fchlewind", "text": "Chairs, I assume my talk will actually not take 15 minutes
", "time": "2026-07-20T13:15:44.000Z"}, {"author": "Eric Kinnear", "text": "Thanks Mirja :)
", "time": "2026-07-20T13:15:57.000Z"}, {"author": "Eric Kinnear", "text": "Re: retries, I feel like that becomes more of a thing once TCP/QUIC backs off exponentially and HEv2/3 doesn't. Versus the conversation around the first or second attempt succeeding is when the original attempts will retransmit on the order of 1RTT later.
", "time": "2026-07-20T13:18:12.000Z"}, {"author": "Erik Nygren", "text": "On the reporting/visibility topic: I should probably send this to the list or bug people in-person, but it would be great if clients could add the HTTP version used int webRequest so extensions like IPvFoo could annotate which was used. (It's a great tool for understanding how FireFox and Chrome end up with for IPv4/IPv6 HappyEyeballs by looking at webRequest.ip but it doesn't appear the h1/h2/h3 is available in a way it can use?)
", "time": "2026-07-20T13:35:11.000Z"}, {"author": "Erik Nygren", "text": "Is HE-style connectivity the real challenge with IPv6 in enterprises? It seems like where things go wrong end up being in IP ACLs, VPN and similar tunnel configurations, split DNS hell, etc.
\nLots of the motivators in some Enterprise is actually getting to IPv6-only as dualstack is less interesting as other than as a necessary stop-gap.