A hotel chain now offers IPv6-only guest Wi-Fi to simplify addressing, yet guests still need legacy IPv4-only booking and streaming sites. The design must require no client software and must preserve DNS behavior for address selection. Which IPv4/IPv6 translation at the boundary best fits this scenario?

NAT64 with DNS64 at the Internet edge is the boundary translation intended for exactly this hotspot model because guests remain single-stack IPv6-only while DNS64 synthesizes AAAA records from real A records for IPv4-only names, letting normal address selection proceed without host changes, and stateful NAT64 then translates those synthesized IPv6 flows to IPv4 on the Internet, which preserves end-to-end DNS semantics and requires no tunnel client or dual address plan. The 464XLAT with device CLAT approach also supports IPv6-only access and even handles literal IPv4 or non-DNS apps better, but it depends on a per-host CLAT function, which directly violates the no-client-software constraint for unmanaged guest devices in hotels. The stateful NAT46 publishing approach is operationally valid for data centers, but it solves the inverse direction by making internal IPv6 servers reachable from the IPv4 Internet and does not give IPv6-only clients synthesized reachability to global IPv4 destinations. The transparent forward proxy approach is widely deployed for guest web filtering and needs no host agent, but it terminates traffic at Layer 7 rather than translating IP, so it breaks preserved DNS address selection and fails non-web ports and streaming apps needing network-layer reachability. For exams, distinguish directionality and where synthesis occurs: NAT64 with DNS64 is IPv6 initiator to IPv4 responder, NAT46 is IPv4 initiator to IPv6 responder, and proxies never synthesize AAAA. In practice, verify the SSID issues only IPv6 with NAT64 prefix discovery and that DNS queries to the provided resolver return synthesized AAAA, then test an IPv4-only hostname and literal to confirm translation without host software.