Greetings Cameron-san,
* On Sat, 29 Oct 2011 20:06:18 +0900 * MAWATARI Masataka <[email protected]> wrote: > Greetings Cameron-san, > > > Cross posting to behave. > > Thank you very much for your comment and sorry for the delay. > > > n900ipv6 is interesting. Thank you for good information. > > The CLAT necessary for function is simple and easy to implement > so the range of application of CLAT can be expanded. > > I agree that 464xlat is applied to mobile network too. > I think that it can utilize a simplicity of implementation on CLAT > and adding a usecase of the mobile network to this draft is possible. > > > You mentioned that this method in this draft don't require DHCPv6. > I agree with you. But I think that there are other proposals must not > use DHCPv6. please let me know about your mention about this point. I'm sorry... I made a mistake. I meant to say "I think that there are other proposals don't require DHCPv6". Kind Regards, Masataka MAWATARI > * On Thu, 27 Oct 2011 13:21:51 -0700 > * 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 -- Japan Internet Exchange MAWATARI Masataka <[email protected]> tel:+81-3-3243-9579 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
