Subject: RE: IPv6 adoption behavior

From: "Michel Py" <[email-masked]>
Date: Tue, 14 Oct 2003 11:26:35 -0700

Fred,

> Fred Baker wrote:
> Frankly, it's not about IPv4 exhaustion, it is about market
> adoption of IPv6.
> IPv4 address exhaustion will never occur. As we approach 100%
> allocation (being now a tad over 60% allocation), the level
> of administrative pushback on a new allocation requests will
> increase, until they get to a point where ISPs will find it
> simpler and more cost-effective to purchase allocations from
> each other. A market will develop, and the price of an
> allocation will change as demand approaches supply.

And as prices rise we can expect a gray market of IPv4 blocks much worse
than what we see today.

> Eventually, the price of purchasing an allocation from
> another ISP will be perceived and used as a competitive
> weapon, and the market will become a very difficult one.
> But supply will never become zero. It will simply become
> expensive. That is economics 101.

Agree. However, this has an unfortunate side effect: Since money will
differentiate the haves from the haves-not, it is a reasonable
assumption that large organizations such as multinational corporations
and developed countries will actually never run out of IPv4 addresses
because they are and possibly will remain in the top tier that can
afford them.

Why is this unfortunate? Because these large organizations can indeed
delay IPv6 deployment until the last minute.

> At the point where it becomes probable that the only or preferred
> way one can access a peer enterprise with which one has or seeks
> a business relationship is via IPv6

Which unfortunately will likely be delayed for the reasons I mentioned
above.

> As it approaches saturation of the current IPv4 Internet, systems
> which choose IPv6 in preference to IPv4 will use IPv6 when they
> can, and IPv4 traffic will start to subside. When IPv4 volume
> becomes too marginal, ISPs will start shutting it down.

Yep.

> The question(s) that raises are "will <pick a point in that game
> plan> ever occur, and if so, when?"

Indeed.

> My crystal ball is as cloudy as anyone's. But I would expect
> that it is all a matter of economics.

I concur.

Michel.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Michel Py" <[email-masked]>
Date: Wed, 15 Oct 2003 00:14:50 -0700

> Christian Strauf wrote:
> it will be difficult to convince sales people that there actually
> is something about IPv6 that can be sold as a feature that makes
> it better than IPv4 (if we leave aside IPv4 address exhaustion
> for the moment).

I'm not so sure that's were the problem really is. Salesdroids would
sell their mother and their shirt if need be; the issue is that they are
typically paid on commission; if IPv6 does not sell they make no money
therefore they'll be back quickly selling IPv4.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 15 Oct 2003 10:30:15 -0400

It is not an IETF task or in the charter and it is being done elsewhere.  This is not even a technical discussion IMO.

/jim

> -----Original Message-----
> From: Christian Strauf (JOIN) [mailto:[email-masked]] 
> Sent: Wednesday, October 15, 2003 2:14 AM
> To: Fred Baker
> Cc: Michel Py; Mark Smith; [email-masked]
> Subject: Re: IPv6 adoption behavior
> 
> 
> > My crystal ball is as cloudy as anyone's. But I would 
> expect that it 
> > is all
> > a matter of economics. 
> I very much agree with you on this point. The problem is that 
> right now it's too hard to sell IPv6 (in the literal sense of 
> the word). I believe that one of the reasons for this is that 
> some features that are theoretically distinctly easier to 
> realise with IPv6, e.g. easier end-to-end security or 
> de-NAT-ification because of bigger address space, need a lot 
> of improvement and development to be deployable in a 
> commercial surrounding. E.g., unless there are (simplified 
> speaking) stable and good interoperable IPsec implementations 
> for improved end-to-end security and a good number of 
> firewalls with stateful filtering to really replace current 
> v4 solutions that employ NAT, it will be difficult to 
> convince sales people that there actually is something about 
> IPv6 that can be sold as a feature that makes it better than 
> IPv4 (if we leave aside IPv4 address exhaustion for the moment).
> 
> It would make sense to look into which implementations need 
> to be programmed first to create a market for IPv6 and to 
> write proposals on what kind of implementations that might 
> be. However, I believe that this is not the IETF's task, or is it?
> 
> Cheers,
> Christian
> 
> -- 
> JOIN - IP Version 6 in the WiN  Christian Strauf
> A DFN project                   Westfälische 
> Wilhelms-Universität Münster
> http://www.join.uni-muenster.de Zentrum für Informationsverarbeitung
> Team: [email-masked]      Röntgenstrasse 9-13
> Priv: [email-masked]    D-48149 Münster / Germany
> GPG-/PGP-Key-ID: 1DFAAA9A       Fon: +49 251 83 31639, Fax: 
> +49 251 83 31653
> 
>

---

From: Dan Lanciani <[email-masked]>
Date: Thu, 16 Oct 2003 03:46:53 -0400 (EDT)

"Christian Strauf (JOIN)" <[email-masked]> wrote:

|I don't think that it is about giving up what you need. With a combined
|v4/v6-capable firewall- and v4-NAT box you could easily achieve the same
|level of isolation of a subnet but without the restrictions for IPv6
|hosts that are forced on v4-hosts by v4-NAT. (In this case: if you want
|to be dual-stacked you keep v4 NAT and use v6 with appropriate firewall
|rules.) So this should not be much of a problem.

But (assuming I'm understanding your setup correctly) you have to restrict
all the local applications that require address stability to using NAT'ed
IPv4 only.  The v6 firewall rules don't isolate you from address changes.
I guess that's ok, but having to select which version of IP to use depending
on whether you want stable local or unstable global access seems at least as
complicated as selecting local vs. global addresses for the same reasons.

				Dan Lanciani
				ddl@danlan.*com

---

From: Dan Lanciani <[email-masked]>
Date: Thu, 16 Oct 2003 16:36:10 -0400 (EDT)

Brian E Carpenter <[email-masked]> wrote:

|Dan Lanciani wrote:
|> 
|> "Tony Hain" <[email-masked]> wrote:
|> 
|> |That said, there are multiple parts to the isolation issue, and even though
|> |most NAT implementations combine them, the discussion will be more
|> |constructive to keep them separate.
|> 
|> I used to believe this, but I recently came to the realization that isolation
|> from provider address policy is a single issue.  
|
|Perhaps, but it is not an issue to which NAT is the only answer.

I never implied that it was.  There are many simple solutions including PI
space handled at the routing level, source routing in any of several forms
including locator/identifier separation, and overlay networks.  Unfortunately,
none of those solutions seems to be able to make it past the politics of
provider-controlled address allocation.  The required technical work to support
them never happens or (in the case of overlay networks) technical tweaks are
implemented to prevent end users from implementing it themselves.

I see two classes on solution:

1) Solutions that require that we make some change to the protocol.  These
would include the approaches I listed above.  If you know of such a solution
that isn't DOA (i.e., that is even allowed to be discussed on this list) then
please describe it.

2) Solutions that end users can implement without change to the protocol.  I
had hopes here for overlay networks, but these still require access to address
space that is not burdened with punitive semantics like default router rules
and DNS prohibitions.  Even with such access it would be difficult to establish
critical mass and turn the overlay network into the primary network.  If you
know of a solution that the market can provide without protocol support (other
than NAT) I'd love to hear about it.

|In IPv6 we have
|enough address space to solve it without NAT. 

Address space was never the problem.  Portable/global/routable address space
available directly to end users (or rather lack of it) is.  You can give the
service providers all the address bits in the universe, but that won't solve
the problem.

People have been claiming for years that IPv6 can deliver the same (or better)
functionality as NAT, but more cleanly.  Recent comments (including some private
email) suggest that this claim carries the unstated assumption that the only
functionality provided by NAT (or at least the only functionality that end users
should be allowed) is conservation of the total address pool.  Assuming folks
really believe this, I think the disconnect with the real world is so great as
to make progress virtually impossible.

				Dan Lanciani
				ddl@danlan.*com

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 19 Oct 2003 21:27:48 -0400

Dan,

As side note.  Outside of the IETF a very coordinated and strong force
is stating NAT business view should not be propogated with IPv6 adoption
and NAT does not provide security and has a great cost.  That body/force
is the IPv6 Forum with Task Forces totally dedicated to the deployment
of IPv6 in almost every geography in the world.  The IPv6 Forum and Task
Forces have the attention of Public Governments/Departments and Private
Enterprise. If we are successful, and I think we will be, the idea of
NAT for IPv6 adoption is dead.  We are now running IPv6 network pilot
across the U.S. and just had successful two week bring-up period of the
new North American Moonv6 network and participation from many entities.
Native IPv6 was run across the U.S. and Native IPv6 with IPsec too.
www.moonv6.org  Moonv6 will stay up too.  

Regards,
/jim

> From: Dan Lanciani [mailto:[email-masked]] 
> Sent: Friday, October 17, 2003 3:34 PM
> To: [email-masked]
> Iljitsch van Beijnum <[email-masked]> wrote:
> 
> |On 17 okt 2003, at 6:29, Dan Lanciani wrote:
> |
> |> NAT is stiff competition--and it is the
> |> incumbent, so being almost as good is nowhere near good enough.
> |> Moreover,
> |> a single solution is appealing exactly because it is a 
> single solution.
> |> You have to take that into account even if it is irrational.
> |
> |So what are you saying?
> 
> I'm saying that IPv6 will be a hard sell since it brings 
> great upgrade costs and offers a reduction in the 
> functionality that people expect and depend on.
> 
> |That we should give up on IPv6 because IPv4 w/NAT is so great that we
> |don't need it?
> 
> By posing this question, are you suggesting that we really 
> can't make IPv6 as great as IPv4+NAT?  Or that we shouldn't even try?
> 
> |Or that we should add NAT to IPv6?
> 
> By posing this question, are you suggesting that the only way 
> to make IPv6 as great as IPv4+NAT is to add NAT to IPv6?  If 
> that is true then the market will take care of adding NAT to 
> IPv6; we don't have to bother.
> 
> |I'm not buying. IPv6 is superior to IPv4 (with and without 
> NAT) in many
> |ways.
> 
> Unfortunately, being "superior" in some abstract sense is not 
> sufficient for something as utilitarian as a networking 
> protocol suite.  We have to examine actual usage requirements.
> 
> |The trouble with networking has always been that even poorly
> |designed networks can work well so there is little incentive 
> to do it 
> |right.
> 
> I don't buy into the idea that users are not entitled to the 
> functionality that they now enjoy just because it is somehow 
> tainted by having once been provided by NAT.  If you are 
> claiming that there is just no way to deliver that 
> functionality with a network that is *not* poorly designed 
> then I think you have to reconsider your definition of "poorly."
> 
> |> NAT was not as painful as it was supposed to be.
> |> For most users, NAT was empowering.  Anyone--even an insignificant
> |> residential
> |> client--could hook up an entire network of their own.
> |
> |But this entire network only enjoys a subset of the capabilities of a
> |network connected without NAT.
> 
> Your statement is extremely misleading, comparing apples and 
> turnips.  It is true that _a_ network connected without NAT 
> enjoys a slightly larger set of capabilities (though they are 
> capabilities that are not important to the typical NAT user) 
> than the same network connected with NAT.  But the 
> residential client in question typically does not have the 
> opportunity to connect _her_ network without NAT because her 
> ISP provides only one dynamic IP address.  The correct 
> comparison, then, is between a NAT-connected network and a 
> network that is not connected to the internet at all.  Which 
> one enjoys greater capability?
> 
> |Application builders are bending over
> |backwards to work within those limits, which costs time and 
> money and 
> |isn't 100% successful.
> 
> Even if this were true, it merely proves that the market will 
> bend over backwards to accommodate the functional 
> requirements of the users.  This is a valuable lesson that we 
> should take to heart.  We cannot ignore those requirements 
> with impunity.  But why did you bring this up at all?  It 
> seems to be part of the argument that NAT is bad (and by the 
> way, I agree that NAT is bad--it just happens to be better 
> than all the alternatives) and therefore we need not provide 
> any of the good things that NAT offers.  Why can't we provide 
> a protocol that offers the same benefits that NAT offers but 
> which does not require application builders to bend over backwards?
> 
> |But this discussion is moot as there is no requirement that IETF
> |protocols are adopted by 100% of all internet-connected systems.
> 
> Wow.  If that renders this discussion moot, wouldn't it 
> render any discussion of anything moot?
> 
> |> It would be interesting to take a poll of people whose ISPs do not
> |> offer
> |> a globally routable IPv4 address
> |
> |That is impossible as ISPs by definition offer access to the internet
> |which means providing globally routable addresss space.  So 
> such an SP 
> |wouldn't be an _I_SP.
> 
> Wow.  I know this whole topic is sensitive, but resorting to 
> acronym games?
> 
> |> |will show that we will
> |> |need well over 400 additional /8's to get a single 
> address to 20% of
> |> the
> |> |population outside the countries that already have one or more for
> |> 20% of
> |> |theirs. This is for an HD ratio of 90% which is well in excess of 
> |> |the
> |> pain
> |> |threashold documented in RFC3194.
> |
> |That's 6.4 billion addresses, a little more than four times what we
> |have available today, for no more than 1.3 billion users. 
> Can someone 
> |please explain where the other 4 addresses per user go?
> 
> I did not write the above quoted text and I have no 
> explanation for it.
> 
> 				Dan Lanciani
> 				ddl@danlan.*com
>

---

From: Dan Lanciani <[email-masked]>
Date: Mon, 20 Oct 2003 01:00:09 -0400 (EDT)

"Bound, Jim" <[email-masked]> wrote:

|As side note.  Outside of the IETF a very coordinated and strong force
|is stating NAT business view should not be propogated with IPv6 adoption
|and NAT does not provide security and has a great cost.

The alleged security feature of NAT makes for a very convenient (and easy to
dispatch) straw man.  NAT's true power for the consumer lies in its ability
to support a flavor of internetworking where none was possible before.  This
capability will not be easily revoked...

|That body/force
|is the IPv6 Forum with Task Forces totally dedicated to the deployment
|of IPv6 in almost every geography in the world.  The IPv6 Forum and Task
|Forces have the attention of Public Governments/Departments and Private
|Enterprise. If we are successful, and I think we will be, the idea of
|NAT for IPv6 adoption is dead.

I've read about legislation that can be construed to ban NAT.  I suppose you
could try to get those "Public Governments/Departments" to step up some sort
of enforcement effort (after all, the cell phone providers got the government
to ban extensions), but short of that I don't see how you can stop the market
from serving its customers.  Even if you can succeed through legal means, I
have to wonder why this is a good thing.  Wouldn't it make more sense to offer
functionality in the base protocol so that users don't feel a need for NAT?

				Dan Lanciani
				ddl@danlan.*com

---

From: Dan Lanciani <[email-masked]>
Date: Mon, 20 Oct 2003 16:36:22 -0400 (EDT)

"Eugene M. Kim" <[email-masked]> wrote:

|I'm afraid this whole series of argument is somewhat misled.  Pardon me 
|if the whole IPv6 landscape has changed while I was asleep, but I always 
|thought that the main goal of IPv6 is not to replace IPv4, IPv4+NAT, or 
|anything that stands well-established today.

I've sort of lost track of the main goal of IPv6; what is it?  This particular
thread was about whether it _can_ replace IPv4+NAT, which clearly it can't
given its current capabilities.  As you point out, this may be of no import
whatsoever since IPv6 isn't going to replace IPv4+NAT...

|If some of you want to say those limitations are not really important to 
|most NAT users, just talk to anyone who played StartCraft behind her NAT 
|box and got frustrated how she and her boyfriend can't play online at 
|the same time because only one machine behind the NAT box can connect to 
|the Blizzard's game server.

But this is not a limitation created by NAT!  The problem comes about
simply because the ISP is providing only a single public address for
NAT to work with.  If the ISP provided two public addresses then two
people on two machines could play at once with or without NAT.  When
the ISP provides only a single address then only one user can play,
with *or without* NAT.  As I mentioned before, it is a testament to
just how well NAT simulates a routed network that people start blaming
it for external restrictions that it could not possibly work around.

|No need to stir up the trouble by shouting `Hey folks, 
|you're all doomed in a sinking ship, whose name is IPv4!'

Suits me...

				Dan Lanciani
				ddl@danlan.*com

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 20 Oct 2003 17:51:02 -0700

> > That said, what actually bothers me is the classic chicken-and-egg
> > problem.  Application writers are reluctant to add IPv6 support
> > because they know that there is little to none of IPv6
infrastructure
> > (read: ISPs supporting IPv6) out there.  ISPs, on the other hand,
> > are reluctant to do IPv6 business because they know that there are
> > few to none of IPv6-ready applications out there. Two-way secret
> > crush. I guess what we need to focus on is how to become a messenger
> > of love. =)
> 
> This analysis is flawed. App developers have little influence over
> deployment and so do ISPs. The market (read, consumer and enterprises)
> decides if a protocol is successful.

The Teredo design is predicated on the idea that we can ship IPv6 as a
software upgrade on the PC. The update can be enabled as part of an
application development. That is actually quite powerful, and does break
the chicken-and-egg problem.

-- Christian Huitema

---

From: "Michel Py" <[email-masked]>
Date: Mon, 20 Oct 2003 18:30:01 -0700

> Eugene M. Kim
> What customers want is to have their needs fulfilled (e.g. to be
> able to play StarCraft online at a LAN party at their houses).
> As long as they get what they want, they are less concerned
> about what technology application developers and ISPs have used
> to implement it. Thus, the ball is back on application developers
> and ISPs' side.

True, but keep something in mind: deploying IPv6 is a huge investment
for ISPs, and the reason they don't deploy is because there is no
consumer demand, _not_ because there are no apps. Good IPv6 apps MAY
trigger demand, and may not.

There are two things that are drive ISP (and most other businesses as
well) investments: fear and greed. Fear to lose customers if they don't
implement a new technology, greed if they see a cash cow on the horizon.
WRT IPv6 today there is neither fear nor greed. Fear and greed comes
from market feedback, nowhere else.

Michel.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 21 Oct 2003 10:11:17 -0400 (EDT)

On Tue, 21 Oct 2003, Benny Amorsen wrote:

>internal network do not notice the failure at all. In the IPv6+firewall
>case the new addresses are provided to the hosts and eventually the old
>addresses time out -- and the internal TCP connection breaks. Ouch.

Not if you have statically assigned IPv6 address space. What if you got a 
/48 from your ISP? Why would this break anything? If we ever get to have 
working PI address allocation this would not break even if you change 
ISPs.

>/Benny

---

From: "Michel Py" <[email-masked]>
Date: Tue, 21 Oct 2003 08:20:43 -0700

> Stig Venaas wrote:
> But there is a big difference between using a 3rd party directory,
> and passing data through an intermediary. That is, you might very
> well have end-to-end connectivity, but use a directory to locate
> the other end-point.

Indeed. But the difference is big technically, which the end user does
care about. As of today, there are several SIP directories that are
jockeying for market share, some offering the service for free. For
these guys, offering an automatic NAT traversal mechanism integrated
with the directory is a big plus, as there is a large potential customer
base that uses NAT.

Michel.

---

From: Dan Lanciani <[email-masked]>
Date: Tue, 21 Oct 2003 23:57:50 -0400 (EDT)

Umm, since folks have decided to perpetuate this thread, I think I'm entitled
to the following disclaimer.  Let's see if I can make this sound all legal. :)
My lack of response--in compliance with the chairs' decision to discontinue
this obviously disturbing discussion--shall in no way be construed to imply
agreement.  Should the chairs wish to reopen any of the associated topics (or
should anyone wish to consider them in some other forum of comparable scope)
I'd be happy to try to clear up some of the misconceptions surrounding (but
not limited to) how routing works, what NAT does, and who's upgrade analysis
may be more "misleading."

				Dan Lanciani
				ddl@danlan.*com