IPv6 consumer perception

Mailman List Mirror (Read Only)
21

From: "Scott Helms" <khelms@ispalliance.net>
To: nanog@nanog.org
Sent: Saturday, 19 February, 2011 8:07:54 AM
Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...)
> Ranking Internet Service Providers by Size
>
> If you take the 5 top US ISPs and get them to do dual stack IPv6,
> that's 50 million subscribers in the US only.
>
> I think google and others will notice some serious traffic
> happening.
We're years from the point where any one of them will have more than a
tiny fraction of their traffic as IPv6 and that's assuming that all we
have to deal with are the known problems.

May be, may be not, but yes non of them are ready like free did to "switch on" IPv6 on their CPE. US ISPs have been caught their pants down. It is going to be ugly.

> It took a market share of 10 to 20% of Mozilla for web developers to
> go back to support ALL browsers. Same for mobile web site a 10%
> surfing rate got many companies to develop web sites for mobiles.

Not really comparable because in both of those cases users were making
a
choice, because they perceived some benefit, and hence there was
demand
to adapt to those new platforms. There is almost 0 demand for IPv6
from
consumers and what is there is from the technologists. We don't have a
situation where the existing infrastructure doesn't work, it does.

Yes there is no demand from consumers, but a consumer on IPv6 is a consumer on IPv6, and that will happen with IPv4 depletion, now once we reach 10% of them, then web analytic tools and email marketing tools and anything that tracks consumer behavior will have to be IPv6 compliant. You don't want to ignore 10% of your consumers, and that was my point.

Google IPv6 traffic is at 0.3%, nice, but hardly significant to have a boss to ask: "I want those IPv6 consumers counted".

I'm looking at where is the critical mass point, when the machine will work on itself, I say 10%.

> If I recall Comcast and Time Warner are participating in IPv6 day.
> This should create enough eyeballs to show on web analytics graph
> and provide the shift that makes nat444 irrelevant.

I wish, but IPv6 day will be much more of a media event than anything
else. Keep in mind that none of these things are what I wish only what
I believe to be accurate.

Sure on IPv6 day they won't light up all their customers, but they made a commitment to be there sooner than later. And yes it is a media event where many companies are saying me too, we are ready, or about to! Or "it will be in next release" which is better than "gosh, there is no demand for that and you are the first one to ask me", which is better than "it will fail".

22

Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts?

- Zed

23

Eyeball demand on ISPs will _NOT_ be the lagging problem in IPv6
deployment.

The consumer side laggage will be CPE and Consumer Eelectronics.

Consumer ISPs are going to be the first ones forced to put subscribers
on IPv6 whether they're ready or not because:

  + Residential Internet Services is the single largest address consumer
  + They pay less for their services than any other class of user
  + In many cases they have few or no choices in provider selection
  + They provide the narrowest margins

These factors mean that providers that are strictly residential will run
out of addresses faster than other providers. Providers which are in
multiple lines of business, including residential are likely to start
harvesting residential addresses for higher-paying services.

The question is whether content providers will recognize and prepare
for this reality before it arrives, or, react to it afterwards.

Owen

24

You can't get yourself an IPv6 Sage certification if you aren't running
IPv6.

http://tunnelbroker.net

Owen

25

Ranking Internet Service Providers by Size

If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only.

I think google and others will notice some serious traffic happening.

Google would probably notice significant traffic increases on IPv6 if they started providing AAAA records
to non-white-listed DNS resolvers.

It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles.

If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant.

They have not yet deployed to more than a handful of trial customers. In fact, I think TW has not yet started
their trials.

For a network operator I'm looking at the ipv6 ipv4 ASN ratio. Once it passes 10% we will have a snow ball effect in the core.

It's just short of 9% today and climbing rapidly.

Toute connaissance est une réponse à une question

The trick is combining the correct knowledge with the right question.

Owen

26

Ranking Internet Service Providers by Size

If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only.

I think google and others will notice some serious traffic happening.

We're years from the point where any one of them will have more than a tiny fraction of their traffic as IPv6 and that's assuming that all we have to deal with are the known problems.

If by years, you mean 18 months and by tiny fraction you mean more than 10%, then, sure, you are correct.

It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles.

Not really comparable because in both of those cases users were making a choice, because they perceived some benefit, and hence there was demand to adapt to those new platforms. There is almost 0 demand for IPv6 from consumers and what is there is from the technologists. We don't have a situation where the existing infrastructure doesn't work, it does.

I'm betting that after IPv4 runout, users will continue to perceive a benefit in making the choice to connect to the
internet even though they cannot get a unique IPv4 address.

If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant.

I wish, but IPv6 day will be much more of a media event than anything else. Keep in mind that none of these things are what I wish only what I believe to be accurate.

The problem with this type of belief is that it serves to incite others to inaction, leading it to become a self-fulfilling
prophecy.

Owen

27

No, but, I am willing to bet that we will not meaningfully make the
situation better for those IPv4-only hosts or the IPv6-only hosts
attempting to reach them by any mechanism more efficient than
encouraging them to add IPv6 capability, whether or not that happens
after the fact.

Owen

28

There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list.

"draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems:

* NAT444 (NAPT44 in the home + NAPT44 in the carrier's network)
* LSN (NAPT44 in the carrier's network, without a NAPT44 in the home)
* DS-Lite (which is an LSN / NAPT44 in the carrier's network)
* stateful NAT64"

I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while
technically accurate isn't particulrarly meaningful.

The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN.

[BEHAVE] comments on draft-donley-nat444-impacts

Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :slight_smile:

I guess that depends on whether you like having customers or not.

Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice).

Of course, tomorrow morning's customers will enjoy communicating with the IPv6 Internet even more, so as somebody else already said: deploy IPv6 alongside any CGN solution.

Cheers,
-Benson

29

IPv6 only hosts are a good thing to speed up v6 adoption. Nothing like a good carrot to get the donkeys moving.

30

There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list.

"draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems:

* NAT444 (NAPT44 in the home + NAPT44 in the carrier's network)
* LSN (NAPT44 in the carrier's network, without a NAPT44 in the home)
* DS-Lite (which is an LSN / NAPT44 in the carrier's network)
* stateful NAT64"

I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while
technically accurate isn't particulrarly meaningful.

The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN.

NAT444 is one implementation of CGN and the issues it describes all apply to NAT444.

It does not claim that it discusses issues unique to NAT444. It claims that all of the issues it discusses
apply to NAT444. That claim is accurate.

[BEHAVE] comments on draft-donley-nat444-impacts

Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :slight_smile:

I guess that depends on whether you like having customers or not.

Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice).

I remain unconvinced of the accuracy of this statement.

Of course, tomorrow morning's customers will enjoy communicating with the IPv6 Internet even more, so as somebody else already said: deploy IPv6 alongside any CGN solution.

Absolutely. Also, I think the intent of the draft is to serve as a further heads-up to content and application
providers that their customer experience in a NAT-444 environment is going to suck and they need to
deploy IPv6. Further, it also serves to provide a guide for help-desks to deal with the consequences of
having deployed a NAT444 solution in their network.

Owen

31

The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN.

NAT444 is one implementation of CGN and the issues it describes all apply to NAT444.

It does not claim that it discusses issues unique to NAT444. It claims that all of the issues it discusses
apply to NAT444. That claim is accurate.

You continue to conflate NAT444 and CGN. I'm not sure I can say anything that hasn't already been said, but perhaps an example will help:

Broken DNS will result in problems browsing the web. That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better.

Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice).

I remain unconvinced of the accuracy of this statement.

Well, if your user does nothing but send email then perhaps even UUCP would be good enough. But for the rest of us, until IPv6 penetration reaches all the content/services we care about, we need dual v4+v6 connectivity.

Cheers,
-Benson

32

Broken DNS will result in problems browsing the web. That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better.

I don't think that's a great analogy. NAT444 is CGN, the web is not
DNS. If I say I can chop down a tree with a red ax, can you disprove
that by saying that you can chop it down with any color ax?

Well, if your user does nothing but send email then perhaps even UUCP would be good enough. But for the rest of us, until IPv6 penetration reaches all the content/services we care about, we need dual v4+v6 connectivity.

If we get dual v4+v6 connectivity quickly enough, we do not need LSN
(including NAT444).

Cheers,
~Chris

33

We don't have a situation where the existing infrastructure doesn't work, it does.

It does today. IPv4 addresses are still freely available today though.

As soon as we introduce LSN, the infrastructure starts to stop
working. When that happens, IPv6 will have demand. Hopefully we can
deploy it before then and avoid the brokeness though...

Cheers,
~Chris

34

Broken DNS will result in problems browsing the web. That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better.

I don't think that's a great analogy. NAT444 is CGN, the web is not
DNS. If I say I can chop down a tree with a red ax, can you disprove
that by saying that you can chop it down with any color ax?

I agree that it's an imperfect analogy, so I won't bother defending it. :slight_smile: But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it.

So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion.

If we get dual v4+v6 connectivity quickly enough, we do not need LSN
(including NAT444).

Amen, brother. I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic timeframes.

Cheers,
-Benson

35

In message <EFD65FF5-12C8-49BE-8243-F081949A5A08@genius.com>, Franck Martin wri
tes:

Ranking Internet Service Providers by Size

If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 m

illion subscribers in the US only.

I think google and others will notice some serious traffic happening.

It took a market share of 10 to 20% of Mozilla for web developers to go back=
to support ALL browsers. Same for mobile web site a 10% surfing rate got ma=
ny companies to develop web sites for mobiles.

If I recall Comcast and Time Warner are participating in IPv6 day. This shou=
ld create enough eyeballs to show on web analytics graph and provide the shi=
ft that makes nat444 irrelevant.

Comcast and Time Warner can enable it, they can't however turn it on in
many cases as it requires the customer to do something.

36

I agree that it's an imperfect analogy, so I won't bother defending it. :slight_smile: But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it.

That I'll agree with. It seems to me that what's called for is an
expansion of the tests done for the draft in question to include
other, currently in-vogue, CGN/LSN technologies.

So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion.

That wasn't the conclusion I drew, can't speak for others of course.
My conclusion is that CGN/LSN is broken, as evidenced by brokenness in
NAT444. I agree that a comparison of all (or some reasonable subset of
all) LSN technologies would be valuable, especially as folks may begin
to be forced to choose one. For now I stick with the ideal: Avoid if
possible. (Dual-stack early, dual-stack often?)

If we get dual v4+v6 connectivity quickly enough, we do not need LSN
(including NAT444).

Amen, brother. I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic timeframes.

Fair enough, I still have hope. =)
~Chris

37

I agree that it's an imperfect analogy, so I won't bother defending it. :slight_smile: But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it.

That I'll agree with. It seems to me that what's called for is an
expansion of the tests done for the draft in question to include
other, currently in-vogue, CGN/LSN technologies.

That's a serious expansion to the testing matrix.

I would rather see those other technologies get their own draft with their
own testing matrix as this is far more likely to be achievable.

So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion.

That wasn't the conclusion I drew, can't speak for others of course.
My conclusion is that CGN/LSN is broken, as evidenced by brokenness in
NAT444. I agree that a comparison of all (or some reasonable subset of
all) LSN technologies would be valuable, especially as folks may begin
to be forced to choose one. For now I stick with the ideal: Avoid if
possible. (Dual-stack early, dual-stack often?)

Agreed.

If we get dual v4+v6 connectivity quickly enough, we do not need LSN
(including NAT444).

Amen, brother. I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic timeframes.

Fair enough, I still have hope. =)
~Chris

My thinking is that faced with disconnection after the fact suddenly causing
me to choose between restoration by dual stacking vs. restoration by NAT444
(or almost any other form of LSN) leads any sane person to restoration by dual
stacking.

Owen

38

So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way?

- Zed

39

I'm advocating not depending on any such interaction working as it's pretty clear that
the available solution set is fairly broken.

I'm advocating not expending significant development resources on enhancing that
situation when it's pretty clear they are better spent facilitating IPv6 deployment to
obviate the need for this level of hackery.

Owen

40

Fair enough. This approach will, however, relegate IPv6-only networks to second class citizenship status. Access to the "real" Internet will require IPv4 and IPv6-only will be seen as the inferior choice, to be avoided as best as you can. Not quite a ringing endorsement for IPv6, in other words.

  This position also assumes that there will be enough IPv4 addresses to go around for everybody to dual stack. Anybody not so fortunate will simply be left out in the cold.

- Zed