Sorry for late response here... On 1/14/2010 15:20, Cameron Byrne wrote:
On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell <jimb@jsbc.cc> wrote:
On 1/14/2010 11:10, Cameron Byrne wrote:
Folks,
My question to the community is: assuming a network based IPv6 to IP4 translator is in place (like NAT64 / DNS64), are IPv6-only Internet services viable as a product today? In particular, would it be appropriate for a 3G /smartphone or wireless broadband focused on at casual (web and email) Internet users? Keep in mind, these users have NAT44 today.
You may also want to read up on Dual Stack Lite (DS-Lite) <http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-02>,
I have looked at DS-lite very carefully. First, DS-Lite fits better for cable operators since they have CPE and can have a DS-lite function in the CPE that they control, and that in turn allows them to provide IPv4, IPv6, and dual-stack to the end-host that they do not control. DS-Lite does not fit as well for a mobile phones since it would require a major change to the phone's OS. Second, DS-Lite requires tunneling as well as translation, so it is one more piece of overhead in addition to NAT64 solution. For me, i believe it is less complex to manage a single stack IPv6 host with NAT64 translation than a dual stack host, tunneling infrastructure, as well as NAT44 CGN, which is what DS-lite requires. They both achieve the same result, but I believe in the mobile space there is a quicker time to market as well as more progress toward the end-goal of IPv6-only using NAT64 than DS-lite.
I guess the choice here is between standing up and managing a NAT64 CGN + special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite tunneling infrastructure (you'd be able to keep existing "vanilla" DNS servers). Presuming you could set up DS-Lite capable routers somewhere in the path, one nice thing about DS-Lite would be that you could allow a mix of dual-stack phones, IPv4 only phones, and even DS-Lite capable phones on the same network. This could be an advantage if IPv6 stacks or DS-Lite virtual nic/tunnel drivers weren't available on all customer phones. Also, as Mr. Durand mentioned earlier, DS-Lite has an advantage in application compatibility too. And, admittedly getting a bit speculative here, by virtue of the fact that a DS-Lite solution would give each phone an IPv4 address, "NAT compatibility" of various applications may also be better on the CGN, since NAT44 is so well understood and generally "worked out" today, where a NAT64 CGN might not support as many "problem apps" which require "fixups" as a DS-lite NAT44 CGN. But if we can presume all phones will have IPv6, and all applications running on them are IPv6 capable, then DNS64/NAT64 would in some ways be cleaner, since it'd eliminate the traffic overhead of tunneling, etc. You'd just have to stand up and manage the DNS64 servers and NAT64 CGNs.
presuming you haven't. I know you mentioned you didn't like any dual-stack solutions, but the thing about DS-Lite I like is that it has no problem with RFC1918 overlap of different customers, since the CGN uses a tunnel ID in the connection/NAT table in addition to the other typical data. I just wonder how it will scale, since each device, or a gateway the device goes though, will require a IPv4-in-IPv6 tunnel to the CGN box(es). Also, it doesn't require a DNS-ALG like NAT64/DNS64.
NAT64/DNS64 does not use a DNS-ALG. DNS-ALG died with NAT-PT. DNS64 is a standalone function which is decoupled from the translation process.
Yeah this is improper terminology I suppose. I use "DNS-ALG" in the IPv6 transition context as a generic term for any specialized DNS server which hacks IPv4 addresses into fake IPv6 addresses for these sorts of purposes, which is further overloading the term I guess. :p Not sure what to use as a better generic term for this. The point I was trying to make is that DS-Lite doesn't require any DNS hackery, unlike NAT64/DNS64, for what it's worth. Anyway, plenty to weigh/consider here. PS: Nice to see the author of the DS-Lite drafts participating here too. :)