Are IPv6-only Internet services viable today?
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. There has been a lot of discussion about CGN / LSN / and other technologies around the corner. In the mobile network operator space, the lack of IPv4 addresses, both public and RFC 1918, has been very real for a long time. In North America, mobile network operators have numbered subscribers with BOGON space (obvious risk) and relaunched multiple instances of RFC1918 space multiple times within their AS (breaking end-to-end even within their own AS, which is a problem with technologies increasingly moving towards any-to-any SIP and IMS). In any event, we can clearly state the addressing issue has compromised both engineering and business decisions in today's major mobile networks. Both scenarios above require tremendous NAT44 infrastructure. And, future CGN technologies don't give me much comfort that things will get better for the operator or the consumer. So, i have been looking more at offering IPv6-only service with NAT64 translation to access the IPv4 Internet. For the network operator, the NAT44 and NAT64 aggregate network state / number of translation is the same to start, and as more native IPv6 content come on the NAT64 gracefully. In fact, given that Google is IPv6 now, and Google is content leader, moving to NAT64 would actually be a reduction in NET NAT translations. IMHO, any dual-stack solution is not an adequate interim solution since both private and public IPv4 addresses are simply not available or will be soon completely exhausted. Dual-stack will have a role in the future, just like public IPv4 addresses have a role today. Dual-stack will be a required service for users with special requirements (legacy IPv4 VPNs ....) , not average web and email users that account for greater than ~80% of a mobile operator's customer base. I also want to stress that this solution best fits new subscribers and devices, it will not be a solution for Window 98 ... or Windows XP in fact. This draft is helpful in understanding the issues as well as the IETF's work on NAT64 draft-penno-behave-64-analysis-02 Some folks in a lab decided to see what type of user experience can be expected using NAT64 and DNS64 and IPv6-only on the end system -- using commonly available hardware and software that's available today, but different from the kit used for the NANOG IPv6 hour. In this case, there is a NAT-PT box in place of NAT64, they used an open source DNS64 implementation, and a standard WIndows 7 Starter edition netbook. I think the conclusion is that casual Internet use, as a product, is possible today. It is not everything IPv4 offers today, but as IPv6 content and applications come on-line the IPv6 capabilities will exceed what IPv4 could do (no NAT for native flows). Screenshot video below, best viewed in HQ mode. This is just a data point with regard to functionality that is akin to NAT64 / DNS64 that is available today. http://www.youtube.com/theipv6guy
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>, 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.
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.
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.
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.
===> DS-lite can work both for fixed and wireless scenario, where you have a laptop/pda/smarphone/tablet that is only configured by the access network with IPv6 but want to access IPv4 content FROM IPv4 applications. This is the main difference between DS-lite and NAT64. NAT64 requires all application on the user device to be IPv6 compatible. Now, that may or may not be an issue. If you are talking about a proprietary wireless device that run only proprietary apps, porting all those apps to IPv6 prior to launching the service may be ok... However, if the device can run external apps, like those coming from an app store, or running pre-existing apps (I¹m thinking about the gazillions apps existing on the iPhone), then a NAT64 solution will force a complete rewrite of every single one of those apps... DS-lite would enable all those apps to keep working. Big difference.
- Alain.
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. :)
On Jan 15, 2010, at 7:53 PM, Jim Burwell wrote:
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).
As I understand DS-Lite, an IPv6-capable device is a DS-Lite capable device without any modification. The DS-Lite Gateway does all the heavy lifting to provide IPv4 services and do the NAT64 translation between the IPv6-only end-user device (phone) and the IPv4 internet. Owen
On 1/15/2010 23:45, Owen DeLong wrote:
On Jan 15, 2010, at 7:53 PM, Jim Burwell wrote:
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 <mailto: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).
As I understand DS-Lite, an IPv6-capable device is a DS-Lite capable device without any modification. The DS-Lite Gateway does all the heavy lifting to provide IPv4 services and do the NAT64 translation between the IPv6-only end-user device (phone) and the IPv4 internet.
Could well be the case. My idea was that you could do it either way. You could have a DS-Lite gateway (Typical. Likely built into the "cable modem" or similar device), or in the case where no gateway is available, a DS-Lite "client" (basically a virtual nic/tunnel driver) on the machine would establish the tunnel and an IPv4 address itself. But perhaps this latter method was never intended?
On 1/16/10 8:03 AM, "Jim Burwell" <jimb@jsbc.cc> wrote:
Could well be the case. My idea was that you could do it either way. You could have a DS-Lite gateway (Typical. Likely built into the "cable modem" or similar device), or in the case where no gateway is available, a DS-Lite "client" (basically a virtual nic/tunnel driver) on the machine would establish the tunnel and an IPv4 address itself. But perhaps this latter method was never intended?
You mean, tunnel directly to the end host? We have been thinking about extensions to allow that 'short-cut', AFTR-less mode. It is doable if you can establish a 1 to 1 mapping between the IPv4 and the IPv6 address **and** you find a way for host A to figure out host B's IPv4 and IPv6 addresses... - Alain.
----- Original message -----
On Jan 15, 2010, at 7:53 PM, Jim Burwell wrote:
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).
As I understand DS-Lite, an IPv6-capable device is a DS-Lite capable device without any modification. The DS-Lite Gateway does all the heavy lifting to provide IPv4 services and do the NAT64 translation between the IPv6-only end-user device (phone) and the IPv4 internet.
Owen
ummm. An ipv6 device is not natively a ds-lite device. There is always a tunneling component which is generally after market client software (in the case of mobile devices) or some cpe function. If you are interested you can read the ietf draft. Assuming you have a ds-lite cpe, you can park dual-stack hosts behind it. But, it does not "just work" today like the demonstration i posted.
On Sat, 16 Jan 2010, Cam Byrne wrote:
interested you can read the ietf draft. Assuming you have a ds-lite cpe, you can park dual-stack hosts behind it. But, it does not "just
If your hosts are dual-stacked, why would you need a ds-lite cpe in the first place? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net
----- Original message -----
On Sat, 16 Jan 2010, Cam Byrne wrote:
interested you can read the ietf draft. Assuming you have a ds-lite cpe, you can park dual-stack hosts behind it. But, it does not "just
If your hosts are dual-stacked, why would you need a ds-lite cpe in the first place?
A dual-stack capable host like windows 7 does not ensure any ipv6 network access beyond the local LAN, especially given todays ipv4-only service dominance. There are various ways to translate or tunnel to solve this problem, connecting v6 and v4 islands, including nat64 and ds-lite
Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net
On 1/16/10 10:52 AM, "Cam Byrne" <cb.list6@gmail.com> wrote:
A dual-stack capable host like windows 7 does not ensure any ipv6 network
access beyond the local LAN, especially given todays ipv4-only >service dominance. There are various ways to translate or tunnel to solve this problem, connecting v6 and v4 islands, including nat64 and ds-lite ===> Well, it all depends on which applications are in use. If the app running on the windows 7 side only works in IPv4 or if the app on the other side is only serving IPv4, there is little choice but to tunnel IPv4 over IPv6 in the middle. See, for many years, when we were thinking about IPv4/IPv6 transition, we looked at it a stack issue. I think we were missing something. We now have seen tons of IPv6 capable stacks (Win XP, Vista, 7, MacOS, Linux, Solaris,...) and still very little apps that take advantage of this, either on the client side, or on the content side. Just ask how many of the 100,000+ apps on the iPhone are IPv6 ready... Btw, on the content side, the situation is quite complex too, because it is not just about configuring apache for IPv6, this is about having a load balancing, content delivery, monitoring,... solution in place. What DS-lite gives you is the ability to de-couple the deployment of the network (including the host stacks) with IPv6 from the deployment of the applications with IPv6. I do believe there is a lot of value in this.
- Alain.
On 1/16/10 10:52 AM, "Cam Byrne" <cb.list6@gmail.com> wrote:
A dual-stack capable host like windows 7 does not ensure any ipv6 network access beyond the local LAN, especially given todays ipv4-only service dominance. There are various ways to translate or tunnel to solve this problem, connecting v6 and v4 islands, including nat64 and ds-lite
It's unfortunate for me that nobody is interested in talking about the question I asked in light of the data i supplied. The question being, is it possible for a mobile operator to offer an IPv6-only service today to casual Internet users on new devices with new service plans? Perhaps it is just a rhetorical question because the video obviously shows it is possible. But, i am legitimately interested in perceived service gaps or issues, given this tightly controlled service definition (web and email). On Sun, Jan 17, 2010 at 7:04 AM, Durand, Alain <alain_durand@cable.comcast.com> wrote:
On 1/16/10 10:52 AM, "Cam Byrne" <cb.list6@gmail.com> wrote:
A dual-stack capable host like windows 7 does not ensure any ipv6 network access beyond the local LAN, especially given todays ipv4-only >service dominance. There are various ways to translate or tunnel to solve this problem, connecting v6 and v4 islands, including nat64 and ds-lite
===> Well, it all depends on which applications are in use. If the app running on the windows 7 side only works in IPv4 or if the app on the other side is only serving IPv4, there is little choice but to tunnel IPv4 over IPv6 in the middle.
Once again, the focus is our ability to deploy today. DS-lite is not here today in off-the-shelf support. It's not a core part of Windows 7 or Android. And, the focus is 90% of my users, not 1% that are running windows 98 or Citrix clients.
See, for many years, when we were thinking about IPv4/IPv6 transition, we looked at it a stack issue. I think we were missing something. We now have seen tons of IPv6 capable stacks (Win XP, Vista, 7, MacOS, Linux, Solaris,...) and still very little apps that take advantage of this, either
All the major web and email apps do IPv6 today (Outlook, IE, Firefox, Chrome, Thunderbird ...), and i don't believe i need to support all the legacy apps, i do have the ability to define explicit terms and conditions of the service. Once gain, i am looking at 90% of my users, not 1%. And, I am further saying that this service would be sold for new devices (new smartphones, new netbooks ...), not legacy devices. I understand your world may be different.
on the client side, or on the content side. Just ask how many of the 100,000+ apps on the iPhone are IPv6 ready... Btw, on the content side, the situation is quite complex too, because it is not just about configuring apache for IPv6, this is about having a load balancing, content delivery, monitoring,... solution in place.
I call FUD. On the app side, how many of those iphone apps just call the web browser or in-built email client? .... such that enabling a few common core elements make the majority of the ecosystem IPv6 enabled. I believe Fred Baker has said that the iphone apps store is an example of IPv6 success in the making -- Quoting: "As to applications, yes, of course. In point of fact, many applications have already been ported to IPv6 and operate just fine. I understand that Apple made a requirement that applications on the iPhone must be IPv6-capable, and as a result several tens of thousands of applications are in fact IPv6-capable." http://www.ietf.org/mail-archive/web/3gv6/current/msg00021.html On the content side, please... How many NANOGs in a row do major players like Google, Netflix, Limelight and others trot on stage and tell us how easy it is to roll out IPv6? I have done content proof of concepts in my lab, enabling my intranet for IPv6 via a VIP on loadbalancer, it took about 45 minutes to figure it out and works flawlessly. Many major load balancer vendors take care of the dirty work for us, such that putting an IPv6 face to the world is easy. The fact that the server is technically IPv4 and the the load balancer is doing protocol translation / proxying is irrelevant and steady-state for the overall architecture in terms of where network state is located. Further, given the consolidation of content to a few major players (2009 Internet Observatory Report), moving IPv6 from where it is today to where it needs to be is getting easier. If Google is ~20% of your traffic, you are already 1/5 the way to being native IPv6.
What DS-lite gives you is the ability to de-couple the deployment of the network (including the host stacks) with IPv6 from the deployment of the applications with IPv6. I do believe there is a lot of value in this.
Yes, value in some environments. Once again, I am not trying to have a religious war. I am just to trying to explore a simple question for my environment based on facts. Thanks for this discussion. -Cameron
- Alain.
On 1/16/10 10:52 AM, "Cam Byrne" <cb.list6@gmail.com> wrote:
A dual-stack capable host like windows 7 does not ensure any ipv6 network access beyond the local LAN, especially given todays ipv4-only service dominance. There are various ways to translate or tunnel to solve this problem, connecting v6 and v4 islands, including nat64 and ds-lite
In a message written on Sun, Jan 17, 2010 at 08:59:00AM -0800, Cameron Byrne wrote:
It's unfortunate for me that nobody is interested in talking about the question I asked in light of the data i supplied. The question being, is it possible for a mobile operator to offer an IPv6-only service today to casual Internet users on new devices with new service plans?
Yes it is possible. Yes you will exclude some segment of customers today.
Perhaps it is just a rhetorical question because the video obviously shows it is possible. But, i am legitimately interested in perceived service gaps or issues, given this tightly controlled service definition (web and email).
I think the phones stopped being "tightly controlled" with the iPhone and Android phones. They expect generic IP connectivty, and are very much not web and e-mail only. Moreso than an IPv6 only provider, a web and e-mail only provider would probbaly find themselves at a huge disadvantage to a significant and growing segment of the market. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 1/17/10 1:01 PM, "Leo Bicknell" <bicknell@ufp.org> wrote: But, i am legitimately interested in perceived
service gaps or issues, given this tightly controlled service definition (web and email).
I think the phones stopped being "tightly controlled" with the iPhone and Android phones. They expect generic IP connectivty, and are very much not web and e-mail only. Moreso than an IPv6 only provider, a web and e-mail only provider would probbaly find themselves at a huge disadvantage to a significant and growing segment of the market.
+1 I made a number of demonstration of mail and web service on an IPv6-only workstation back in early 2000, in my Solaris days. Even ten years ago, it was clear this would not be enough... - Alain.
On 1/17/10 11:59 AM, "Cameron Byrne" <cb.list6@gmail.com> wrote:
It's unfortunate for me that nobody is interested in talking about the question I asked in light of the data i supplied. The question being, is it possible for a mobile operator to offer an IPv6-only service today to casual Internet users on new devices with new service plans? Perhaps it is just a rhetorical question because the video obviously shows it is possible. But, i am legitimately interested in perceived service gaps or issues, given this tightly controlled service definition (web and email).
I would hope my last emails start to address this point. The single most impediment I see to deploy IPv6-only networks is the combined effect of the 2 long tails: on one side, the content is today mostly IPv4-only accessible, making it a disincentive to build v6-only access network, and on the other side, the apps are for the vast majority IPv4 centric, making it a disincentive to offer content over IPv6, to build an Ipv6 capable device that cannot use those apps or to build v6-only access networks in the first place... This realization was the starting point of the development of the DS-lite technology. - Alain.
On 1/16/2010 07:01, Antonio Querubin wrote:
On Sat, 16 Jan 2010, Cam Byrne wrote:
interested you can read the ietf draft. Assuming you have a ds-lite cpe, you can park dual-stack hosts behind it. But, it does not "just
If your hosts are dual-stacked, why would you need a ds-lite cpe in the first place?
The point of DS-Lite is to provide IPv4 internet access to hosts which only have IPv6 addresses in an IPv6 only network environment. That is, IPv4 connectivity isn't available all the way through to the provider's CGN. If you did straight dual-stack, the provider would have to do IPv4 connectivity all the way to the CGN, and also maintain unique RFC1918 IP address assignments to every customer going through a particular CGN. With DS-Lite, the IPv4 traffic is tunneled from a DS-Lite router fronting the customer's LAN, or from a host itself (a presumption) running some sort of DS-Lite driver. Because the traffic can by identified by the CGN from the tunnel it came in on, the RFC1918s don't have to be unique (the customer can pick whatever he wants for his/her LAN). A full DS network isn't needed throughout the entire provider infrastructure, hence the name DS "Lite".
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?
Well, speaking for CERNET2 (2nd Gen. of China Education and Research Network), it is a "production" network today in the sense that it connects 100+ china universities, and it runs IPv6 only.
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.
That's actually a very good question. My personal take is 3G/4G *is* the best fit to IPv6, and it will be a win-win situation if we combine them together. At wireless side, there will be a LOT more addresses, unblocked end-to-end communication, location and ID separation, and maybe more new applications based on information carried in IPv6 header. At IPv6 side, we need larger user base, more contents, more applications to make IPv6 really take off, and 3G/4G can make that push. Regards, Leon
Hello, Thank you for launching such useful discussions for operators. IPv6 introduction in mobile networks is certainly one major issue we have to consider for services and business development. As you stated, pressure on public and private IPv4 addresses is more and more important and we have to envisage IPv6 deployment in following years to avoid issues you are presenting in your mail. To do so, I think we need to converge on IPv6 introduction scenarios and requirements before investgating technical solutions. For example, if one trigger for IPv6 introduction is the lack of IPv4 addresses, we can not rely on some dual stack connectivity for IPv6 introduction and the only perennial solution will consist in allocating IPv6 only prefixes to UE, allowing to identify them without any ambiguity at least. Once such option has been retained we have to consider valid scenarios. Do we want that these only-v6 connected terminal access to IPv4-only Internet and walled garden services ? Do we want that some (piece of) IPv4 applications on the terminal access to IPv4 applications with an IPv6-only connectivity ?...IPv6 only services may be relevant, at least in some further stages of IPv6 integration. Once we have retained valid scenarios we have to deploy technical solutions to answer such needs. NAT64 for example may be needed but it has to be challenged with other solutions, including proxys solutions, DS-Lite, A+P...Actually NAT64 that is a flavor of NAT44, already largely deployed in mobile networks, may be a solution hoping that applications will be more and more DS and that IPv6 native communications will grow. I think we have to avoid some technical solutions based on some several translation mechanisms for an IP session. David
-----Message d'origine----- De : Cameron Byrne [mailto:cb.list6@gmail.com] Envoyé : jeudi 14 janvier 2010 20:10 À : nanog@nanog.org Objet : Are IPv6-only Internet services viable today?
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.
There has been a lot of discussion about CGN / LSN / and other technologies around the corner. In the mobile network operator space, the lack of IPv4 addresses, both public and RFC 1918, has been very real for a long time. In North America, mobile network operators have numbered subscribers with BOGON space (obvious risk) and relaunched multiple instances of RFC1918 space multiple times within their AS (breaking end-to-end even within their own AS, which is a problem with technologies increasingly moving towards any-to-any SIP and IMS). In any event, we can clearly state the addressing issue has compromised both engineering and business decisions in today's major mobile networks. Both scenarios above require tremendous NAT44 infrastructure. And, future CGN technologies don't give me much comfort that things will get better for the operator or the consumer. So, i have been looking more at offering IPv6-only service with NAT64 translation to access the IPv4 Internet. For the network operator, the NAT44 and NAT64 aggregate network state / number of translation is the same to start, and as more native IPv6 content come on the NAT64 gracefully. In fact, given that Google is IPv6 now, and Google is content leader, moving to NAT64 would actually be a reduction in NET NAT translations.
IMHO, any dual-stack solution is not an adequate interim solution since both private and public IPv4 addresses are simply not available or will be soon completely exhausted. Dual-stack will have a role in the future, just like public IPv4 addresses have a role today. Dual-stack will be a required service for users with special requirements (legacy IPv4 VPNs ....) , not average web and email users that account for greater than ~80% of a mobile operator's customer base. I also want to stress that this solution best fits new subscribers and devices, it will not be a solution for Window 98 ... or Windows XP in fact. This draft is helpful in understanding the issues as well as the IETF's work on NAT64 draft-penno-behave-64-analysis-02
Some folks in a lab decided to see what type of user experience can be expected using NAT64 and DNS64 and IPv6-only on the end system -- using commonly available hardware and software that's available today, but different from the kit used for the NANOG IPv6 hour. In this case, there is a NAT-PT box in place of NAT64, they used an open source DNS64 implementation, and a standard WIndows 7 Starter edition netbook. I think the conclusion is that casual Internet use, as a product, is possible today. It is not everything IPv4 offers today, but as IPv6 content and applications come on-line the IPv6 capabilities will exceed what IPv4 could do (no NAT for native flows).
Screenshot video below, best viewed in HQ mode. This is just a data point with regard to functionality that is akin to NAT64 / DNS64 that is available today.
********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ********************************
participants (9)
-
Antonio Querubin -
Cam Byrne -
Cameron Byrne
-
david.binet＠orange-ftgroup.com -
Durand, Alain -
Jim Burwell -
Leo Bicknell -
Owen DeLong -
Xiaoliang Zhao