Are IPv6-only Internet services viable today?

Mailman List Mirror (Read Only)
1

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

2

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.

3

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&gt;,

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.

4

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

5

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

6
7

Sorry for late response here...

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&gt;,
    

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. :stuck_out_tongue: 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. :slight_smile:

8

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

9

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?

10

> Sorry for late response here...
>
> >
> > >
> > > > 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&gt;,
> > >
> > 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.

11

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

12

> 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

13

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".

14

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.

15

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.

16

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

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."

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

17

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.

18

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.

19

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.