Hi Chongfeng, Thank you for your review! Comments inline. On Sun, Jul 13, 2025 at 11:27 AM Chongfeng Xie via Datatracker <noreply@xxxxxxxx> wrote: > 1) Regarding NAT64 definition in Section 2，in the context of this draft, NAT64 > should be Stateful NAT64 (RFC6146), so I suggest that this definition is > revised to be consistent with the definition in RFC8781. Strictly speaking, NAT64 can operate in stateful mode (as PLAT side normally does) and in a stateless one. CLAT usually operates in a stateless mode, and uses the PREF64. We have updated the text to mention CLAT explicitly. > 2) Section 4.1 is about the recommendation to operators, considering that > operators do not have control to the end-point industry, I suggest section > 4.1.2 is moved from section 4.1 and considered as a seperate secion, for > example, section 4.2. Done. > 3) While PREF64 approach defined in RFC8781 offers advantages, its RA-based > discovery mechanism requires configuration on all user-side interfaces of edge > devices. In production networks with numerous edge devices, this approach > imposes significantly higher configuration and management overhead compared to > DNS-based RFC 7050 solutions. By contrast, DNS64 deployed on a central DNS > server can serve a broad user base, reducing operational complexity. To ensure > operators have a complete understanding, it is also recommended to mention this > in an appropriate manner. To be honest, we (the authors) disagree. If the network uses 7050, all user-facing interfaces still have to be configured, so the RDNSS option is included into RAs, to provide hosts with the DNS64 configurations. (Not mentioning other SLAAC configurations like PIO etc). If RFC8781 is used instead, the RA needs to include just another RA option, for PREF64. > 4) Nit: "3. Existing Issues with RFC 7050"--->"3. Existing Issues with > RFC7050" Fixed, thank you! -- Cheers, Jen Linkova -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
