I like the ideas in this draft. A few comments: 1. I think this idea of NAT464 is very applicable, especially in mobile networks. There is already a similar NAT464 deployment here https://code.google.com/p/n900ipv6/wiki/README ....Running code, running architecture, running network are all proven today... I think it makes sense to think of the CLAT as a mobile phone, or at least consider it as a use case.
2. If we can consider the mobile network use case, it may make sense to broaden the scope to not exclude DNS64 and not require DHCPv6. Mobile networks do not generally use DHCPv6. My ideal case would be to allow DNS64 to facilitate as much native and single translation traffic as possible, while minimizing and enabling the double translation traffic where it is needed (IPv4 sockets, IPv4 literals, ...). 3. Since DHCPv6 is not used in mobile, it may make sense to add a scenario to learn the NSP PREF64 of the NAT64/DNS64 from this work draft-ietf-behave-nat64-discovery-heuristic-03 4. So, adding a mobile scenario would be to have CLAT in the phone, DNS64 and NAT64 in the network, and CLAT does draft-ietf-behave-nat64-discovery-heuristic-03 to discover NSP. I believe this solves an important problem for mobile phone and mobile networks that must go IPv6-only. Today, NAT64/DNS64 on mobile phones work well, but there is a small minority of applications that cannot work, and this N900 code i showed above has proven to overcome these limitations. I believe this draft can provide a generic frame work for mobile as well as fixed-line that works well if we slightly increase the scope as mentioned above. 5. Finally, i think this work should be moved to BEHAVE. AFAIK, BEHAVE is not closed and BEHAVE is the right space for this architectural work that uses the BEHAVE standards. Cameron _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
