| Newsgroups |
gmane.ietf.dnsop,gmane.ietf.v6ops |
| Message-ID |
<[email protected]> |
However, if implemented for self-synthesis (no need to change the protocol), usage will increase (at least while we still have IPv4-only services), and there is no any risk or harm.
Actually will be good if it becomes a MUST for draft-ietf-6man-rfc8504-bis.
In any case, my main point is still if people that implemented it in the network has actually got broken DNSSEC. I haven’t seen that.
Regards,
Jordi
@jordipalet
> El 13 abr 2026, a las 15:27, Tim Chown <[email protected]> escribió:
>
> Hi,
>
> I’m minded NOT to advance DNS64 to IS. Pretty much exactly for the reason implied in Michael’s final paragraph below.
>
> It is widely implemented, and there are multiple implementations, but at the same time there very much is a health warning to be carried with it, and its use will (hopefully) decrease over time. It served a purpose, but we’ve learnt and moved on.
>
> We need that health warning to be clearly stated, noting that DNS64 serves a purpose (with caveats) particularly for devices that will never see a host-based shim supported, as Michael points out.
>
> Tim
>
> On 10/04/2026, 18:12, "Michael Richardson" <[email protected]> wrote:
>
>
> DNS64 should be advanced to IS, but it can include (IESG or author) notes
> that *hosts* should aim to move to PREF64/etc. as written extensively in
> RFC8683.
>
> It's very useful for networks to be able to deploy DNS64 for hosts that are
> either older (or are dual-stack capable from 2003, but operating IPv6-only),
> or which want to have *no* IPv4, or whose local infrastructure becomes v6-only.
> (They really only need a CLAT if they have v4-literals. I've run lots of
> v6-only hosts for ~15 years, long before CLAT)
> They do DNS requests to a local recursive nameserver (whether Do53 or
> DoX), on which DNSSEC and AAAA-synthesis occurs.
>
> There are *many* reasons to have such older hosts, and to *not* do major upgrades.
> For instance, because they support applications deployed to systems that are
> not, or never replaced: embedded systems for buildings, aircraft, ...
> Remember, "host" can be a VM, or a even just a container.
>
> {Many decades ago, when a WGA at BNR, I found a "devops" guy with what was
> already a super ancient HP9000 series 300 workstation on/under his desk.
> Because that was the build system for one generation of DMS-10. His
> email/cocos wouldn't work anymore. He got an NCD X-terminal that afternoon,
> and this critical build system got moved to the data center room. We
> considered if we should/could do that without cutting the power to it, as it
> also hadn't rebooted in ~6 months. It was fine}
>
> So while DNS64 should be deprecated for hosts going forward, it needs to be
> available as network infrastructure (in a trade-agreement compatible RFP'able
> way) for some time.
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
> ** My working hours and your working hours may be different. **
> ** Please do not feel obligated to reply outside your normal working hours **
>
>
>
>
> _______________________________________________
> v6ops mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]