Hi Cameron, I think draft-mawatari-softwire-464xlat is about 4rd, they don't clearly say which approach they are taking but it seems like it is from murakami-softwire-4v6-translation, this draft is in the reference list but not referenced.
Of course in 4rd you don't DNS64 due to the double translation. BTW, mobile networks do have DHCPv6, even on the UE itself since Release 10, you like it or not. Regards, Behcet On Thu, Oct 27, 2011 at 3:21 PM, Cameron Byrne <[email protected]> wrote: > 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 >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
