A campus has thousands of IPv6-only IoT sensors that must reach an IPv4-only building management platform and public IPv4 DNS names, with no plan to dual-stack the sensors. The team needs automatic address synthesis and name resolution without per-device static mappings. Which translation design at the boundary fits, and which pairing applies?
Select an answer to reveal the explanation.
Short Explanation
Your sensors speak only IPv6, while the platform speaks IPv4, so they need a bridge that works without hand-configuring every device. DNS64 synthesizes the address NAT64 needs to carry their traffic to the IPv4 service.
Full Explanation
NAT64 with DNS64 fits because DNS64 synthesizes AAAA records from IPv4-only A records using the NAT64 prefix, and the boundary NAT64 performs stateful address and protocol translation. This lets unmodified IPv6-only sensors initiate connections to the IPv4-only platform and reach public IPv4 names without per-device entries. 464XLAT with a CLAT on each sensor is a proven design, but it requires a translation stack on every constrained device to reach the boundary PLAT, adding firmware cost that does not fit this requirement. Static stateful NAT64 mappings can support deterministic inbound access to servers, but manually provisioning bindings for thousands of sensors does not provide the required automatic operation. An HTTP and MQTT reverse proxy can modernize those selected services, but it needs per-service listeners and certificates and does not synthesize addresses or provide transparent reachability for arbitrary IP traffic. As an exam caveat, NAT64/DNS64 is for IPv6-only clients initiating connections and depends on their using the DNS64 resolver; clients that bypass it may not receive synthesized AAAA records. As a practical check, verify PREF64 advertisement, DNS64 resolver assignment, synthesized AAAA responses, and NAT64 session capacity with pilot sensors before fleet rollout.