Are IPv6-only Internet services viable today?

Sat Jan 16 03:53:43 UTC 2010

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 at 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.  :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5570 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100115/7424f1a1/attachment.bin>