Subject: Re: IPv6 adoption behavior

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

Iljitsch van Beijnum <[email-masked]> wrote:

|On 17 okt 2003, at 21:34, Dan Lanciani wrote:
|
|> |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.
|
|I don't see the upgrade costs for regular users. Users are by now used 
|to upgrading monthly (if not more often) to plug the latest and 
|greatest security holes, so a software upgrade to install IPv6 
|functionality somewhere in the next three years or so isn't a huge 
|hardship.

I strongly doubt that IPv6 will be available as a software-only upgrade
for any but the latest equipment.  There is just too little incentive for
vendors (especially ones who have gone out of business :) to support "legacy"
hardware (where "legacy" seems to mean over six months old).

|Functionality won't disappear unless people turn off IPv4, which I 
|don't expect them to do.

Sure, but that's basically saying that IPv6 + IPv4+NAT can replace IPv4+NAT,
which isn't very interesting. :)

|(I even get strange looks from people in IPv6 
|circles when I say I want to run IPv6-only hosts for test purposes.)

That's a rather telling response...

|> |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?
|
|As long as IPv6 isn't a full superset of IPv4+NAT then it's going to be 
|possible to argue that "IPv6 isn't as great as IPv4+NAT".

Well, your words, but it really isn't about arguing whether it is as great.
Remember that the original assertion that I questioned was that IPv6 could
substitute for IPv4+NAT.  I think we have a long way to go before it can.

|But I think 
|we can and should add all the missing stuff to IPv6.

Naturally I agree, but it seems like one of the key features (address
independence) is a stumbling block.

|> |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.
|
|If we're going to be doing NAT anyway why bother with IPv6?

I've been wondering that myself lately.  Possibly IPv6 will be useful in
circumstances where the provider can control the user's environment via
restricted firmware, legal means, etc.  (The canonical example seems to
be smart phones.)  Possibly IPv6+NAT will be marginally useful by slightly
lowering the barriers to low-end-business connectivity while leaving the
residential users with NAT.  None of this sounds particularly revolutionary,
but it could be evolutionary.  Still, this doesn't answer the question of
whether we *can* make IPv6 a superset of IPv4+NAT without making it IPv6+NAT.

|> |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.
|
|Yes. But note that this doesn't have to be the actual end-user.

I understand that actual end-user requirements are not a major consideration
for IPv6 development.  This has been discussed before and I've commented that
I'm not thrilled with the decision to concentrate on provider requirements,
but I can't raise a technical objection because it isn't a technical issue.
On the other hand, you can only push this so far.  Eventually you have to
convince the end-users to use the service or it will fail.  End-users have
evolved a bit over the years.

It's funny; I remember having essentially the same discussion of addressing
considerations years ago.  This was way before CIDR, when pretty much anyone
could get potentially routable address space, but you couldn't get it routed
unless you were a direct business-class customer of one of the proto-ISPs.  My
lament was that the business models of the proto-ISPs precluded the kind of
structure I was hoping for:  an individual networks his own computers and
connects that network to the internet as in the pre-commercial model.  The
counter was that individuals didn't want or need such capability and wouldn't
know what to do with it if they had it (presumably generating lots of tech
support calls).  Only nerds who remembered the old internet would be interested
in such things.  To a first approximation this was correct, but the real reason
remained the service differentiation for direct customers who paid the big fees.
So, long before anyone was talking about address depletion, the value of usable
routable address space was recognized.  As it is today.  As it will be no matter
how big the address space becomes.

Post-CIDR (really post-provider-controlled-address-allocation) a generation
of users grew up with little or no knowledge of the original internet model.
They viewed their internet connection more as a media service than as a pipe
for packets.  Then along came consumerized NAT.  Without even realizing how
the internet had once worked, users started "sharing" their internet service
among their own computers and eventually even further.  They were building
networks.  Granted, there were a number of factors that made this all possible:
the proliferation of personal computers, the simplification of configuration,
even the success of wireless.  Whatever the cause, this is now a commonly
understood activity.

The point of this long-winded story is that the genie is out of the bottle.  It
isn't a matter of a few aging nerds this time.  The public (technical public
perhaps, but becoming less and less so) knows the power of internetworking.
They aren't going to give it up easily.  We can embrace their requirement or we
can try to turn back the clock.  The latter will take more than telling the
users that what they are doing is evil (the ISPs already tried that), and it
will take more than a few NAT-hostile applications to block the NAT solution.
I see three possible paths:

-We do something to satisfy the users' requirements without making them resort
 to NAT, possibly upsetting providers who will need to adjust their business
 models.

-We do nothing special and the market supplies IPv6 NAT.  Things stay pretty
 much as they are.

-We do something radical to prevent users from employing NAT-like solutions,
 possibly failing by succeeding if those users reject the protocol.

|> |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.
|
|Well, there was a time when I had email without spam too. Sometimes 
|progress isn't progress.

This is a rather strained analogy. :(

|It is becoming quite apparent that having a 
|stable internal network and an ephemeral externally reachable network 
|provide seamless functionality can only be achieved using very dirty 
|hacks.

It is not at all apparent to me.  There are many ways to achieve that goal
including PI space handled directly at the routing level, various forms of
source routing including locator/identifier separation, and overlay networks.
Now if you qualify your statement by saying that there are no politically
acceptable approaches I might agree.  Ditto if you say that there are no clean
approaches that can be implemented by the end-user without our doing something
to the protocol.  But let's try to keep the genuinely technical limitations
separate from the limitations necessary to accommodate current business models
that assume that an end-user cannot acquire address space.

|The internet supported address portability until 10 years 
|ago. This was a poor design because it doesn't scale, regardless of the 
|usefulness of the functionality.

This is a common but confusing generalization.  Portable address usage grows
linearly in the actual number of users.  It is very hard to do better than this
without NAT-like hacks.  Even those merely divide by a constant without changing
the order of growth.  On the other hand, hierarchical provider-based allocation
consumes addresses exponentially in the number of provider levels, assuring
that there will always be an address shortage at the lowest level(s).

The confusion comes about because people used the scalability of "address
portability" as a rather ambiguous shorthand to describe various problems in
the current routing model.  Initially it seemed to refer to the actual size
(i.e., memory use) of the routing table in a full-knowledge system.  Even this,
though, grew only linearly with the number of addresses, so it took some fancy
footwork to come with the desired "exponential growth" catch-phrase that was
supposed to end all debate.  As near as I can figure, the notion was that the
usage of addresses was growing exponentially in *time* so the routing table
was also.

Increasing hardware capability has taken the wind out of the memory size
argument, so the current fashion seems to be to consider the computational load
of building the table in the first place, again constraining the process to
work exactly as it does today.  This is a harder problem to overcome by brute
force, but it still has nothing to do with the scalability of portable addresses
themselves.  It just means that we can't necessarily support an arbitrary number
of portable addresses *and* still constrain the routing process to work exactly
as it does today.

One obvious approach (if we did want to support portable addresses) is to return
to a dumb network/smart host model and push the route computation to the edges
of the network where the available resources grow with the consumers.  Routers
could go back to simply forwarding packets as fast as possible rather than
spending lots of cycles enforcing economic policies by applying complicated
filters to AS paths to determine whether this or that network really deserves
transit service.  Of course, this would require a change in provider business
model because they would not have the fine-grained control currently used to
leverage peering agreements.

It looks like you snipped a question.  Here it is in context:

|> 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?

				Dan Lanciani
				ddl@danlan.*com

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

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 20 Oct 2003 10:49:07 +0200

-----BEGIN PGP SIGNED MESSAGE-----

Dan Lanciani wrote:

<SNIP>

> I strongly doubt that IPv6 will be available as a 
> software-only upgrade for any but the latest equipment.  There is just too little 
> incentive for vendors (especially ones who have gone out of business :) to 
> support "legacy" hardware (where "legacy" seems to mean over six months old).

Endusers usually only have their OS's and some kind of access device.

OS's (Windows, Linux, Solaris, *BSD) all have IPv6 support.

As for the access devices this indeed differs as there are
a couple of techniques to get the IPv6 to that enduser.

Most of the access devices are too simple and are mostly NAT boxes
nowadays which most people call 'routers' (ouch). These won't sport
IPv6 quickly indeed but we have a number of transition mechanisms
to overcome that problem fortunatly. As Jordi Palet's draft points
out most of the NAT's can be configured per software to allow
IPv6 over IPv4 tunnels, using Teredo we fix anything else.

There is a reason btw why Microsoft invented Teredo, they where
running into much too many barriers and hooks when wanting to
deploy internet-worked gaming for both Xbox and Windows platforms
where NAT's are the culprit as the hosts don't have global
addressability which really really is the biggest problem of IPv4
because many ISP simply don't pass you more than one IP because
that is their business plan and you have to give them much more
money for those IP's. Basically that boils to:

ISP's should sell bandwidth *NOT* IP space.

They should ofcourse only route the IP's delegated to the enduser.
And not anything else.

> Sure, but that's basically saying that IPv6 + IPv4+NAT can 
> replace IPv4+NAT, which isn't very interesting. :)

It is perfectly interresting as I have been using this setup
personally for almost the last 3 years now using a smoothly
running IPv6 tunnel. It's very useful when having only 1 IPv4
address and a /48 IPv6 @ home allowing all the machines to
really communicate with eachothers. With the advent of Netmeeting
sporting IPv6 and various VoIP applications this will become
very interresting as it solves all the NAT problems.

> That's a rather telling response...

One can do with 1 IPv4 address just like now: NAT it :)

> Remember that the original assertion that I questioned was 
> that IPv6 could substitute for IPv4+NAT.  I think we have
> a long way to go before it can.

IMHO it can when most applications are upgraded to use IPv6.
When the gaming industry (Sony's Playstation, Microsoft's Xbox)
pick up internetworked gaming this will lift off.

> independence) is a stumbling block.

Then we really need to fix that.

<SNIP>

> I've been wondering that myself lately.  Possibly IPv6 will 
> be useful in circumstances where the provider can control the user's 
> environment via restricted firmware, legal means, etc.

There is no way to stop a user which you gave some method of
reaching an outside server which is not under you control
to tunnel anything through that connection including IPv6.

<SNIP>

> I understand that actual end-user requirements are not a 
> major consideration for IPv6 development.

The enduser wants one thing: it needs to work(tm)

> an individual networks his own computers and
> connects that network to the internet as in the 
> pre-commercial model. 

Which won't scale as that would require to much routing
information and administration in the RIR's.

<SNIP>
> -We do something to satisfy the users' requirements without 
>  making them resort to NAT, possibly upsetting providers who
>  will need to adjust their business models.

The typical enduser that plays games, does filesharing and
communicates with others (MSN/ICQ/Jabber/...) requires
global addressability to do these functions, they don't want
NAT. But they don't complain because there is nothing else.

<SNIP>

> -We do something radical to prevent users from employing 
> NAT-like solutions, possibly failing by succeeding if those
> users reject the protocol.

You can't prevent this in any way, a user can do with their
IP whatever they want and they will. You can disencourage them
though just like ISP's threaten users to 'disconnect users who
use their service with more than one computer' just if that ISP
can see that you are using more than one with MSN :)

<SNIP>

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

Let me put it this way: they want their mp3's (-> warez).
Thus they need to do P2P as they know no other way.
This requires a non-NATted IP.
They want to game, which requires a client and a server.
Of at least the server needs to be non-NATted.
If 2 friends have NAT networks and usually they do nowadays
they can't play their favourite expensive game together
because they are stuck behind a NAT.

> 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?

The NAT connected network with an IPv6 tunnel :)

Greets,
 Jeroen

---

From: "Eugene M. Kim" <[email-masked]>
Date: Mon, 20 Oct 2003 12:22:54 -0700

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.

There are some holes that the current IPv4 with NAT can't reasonably 
plug in a sound manner; as Jeroen pointed out, it could be PC/Xbox/PS2 
games, NetMeeting, or heaven forbid, P2P warez (I don't want IPv6 to be 
flagged as a pirate ship by the government =p).  IPv4+NAT can work 
around this, but only with dirty hacks.  And in many cases these hacks 
are not 100% complete either.

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.  Just in case you didn't know, StarCraft is 
still quite popular among kids and teens (it's even an official event in 
an international gaming competition; see www.worldcybergames.com), so I 
guess it's a bit hard to say it's not important to most NAT users.  *grin*

Anyhow, I think that these niche markets are the number one target of 
IPv6.  And one day, with people realizing what P2P is and how they 
actually need it (from their own practical point of view of course; see 
above), the niche markets won't be niche markets anymore.

Yes, it would be also good if IPv6 could `replace' IPv4+NAT one day.  
But it'd be like putting the cart before the horse to say IPv6 doesn't 
have much chance because it can't replace IPv4+NAT easily.  Because that 
is not the only purpose of IPv6.  I mean, if that replacement actually 
happens, good.  If it doesn't happen, who cares?  IPv6 will have its own 
market anyways.  No need to stir up the trouble by shouting `Hey folks, 
you're all doomed in a sinking ship, whose name is IPv4!'

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

Cheers,
Eugene

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 21 Oct 2003 09:33:50 +0200

--On Monday, October 20, 2003 00:23:04 -0400 Dan Lanciani
<[email-masked]> wrote:

> vendors (especially ones who have gone out of business :) to support
> "legacy" hardware (where "legacy" seems to mean over six months old).

My SparcStation 4 machines all run v6. They were built around 1995, iirc.
We have a Cisco 7507 router in SUNET, bought around 1996, which runs v6. 

Do you need more examples? 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 21 Oct 2003 13:50:11 +0200

On 20 okt 2003, at 6:23, Dan Lanciani wrote:

> |I don't see the upgrade costs for regular users. Users are by now
> |used to upgrading monthly (if not more often) to plug the latest and

> I strongly doubt that IPv6 will be available as a software-only 
> upgrade for any but the latest equipment.

This is indeed a problem for some types of equipment, such as 
multilayer switches. Those typically have IPv4 hardware on board which 
isn't easily upgradable. However, this isn't very relevant to end-users 
who spend most of their money on general-purpose computers that can be 
upgraded with new software. But all the main operating systems support 
IPv6 in their latest versions today anyway.

> There is just too little incentive for vendors (especially ones who 
> have gone out of business :) to support "legacy"

Yes, that's why I have to buy a new GSM phone to get new features 
rather than simply update the software. Small stuff such as residential 
"routers" could be upgraded with new firmware but it's more likely that 
the vendors want to sell new boxes. Given the prices for this stuff I 
don't see a huge problem here. For the expensive stuff such a vendor 
policy wouldn't be accepted.

> Sure, but that's basically saying that IPv6 + IPv4+NAT can replace 
> IPv4+NAT, which isn't very interesting. :)

Why not? This way you get to have the best of both worlds: run existing 
NAT-compatible v4 apps without having to wait for v6 upgrades, but also 
run stuff that won't work over NAT.

> That's a rather telling response...

Telling what about who?

> independence) is a stumbling block.

Have a look at what's happening with locator/identifier separation in 
the multi6 working group. A batch of new drafts is on its way.

> I've been wondering that myself lately.

However, note that if we want to get NAT right (ie support incoming 
connections and referential integrity) we need just as many painful 
changes as we need for adopting IPv6. The difference being that IPv6 is 
here today, even if some desired features are still missing.

> Possibly IPv6 will be useful in circumstances where the provider can 
> control the user's environment via restricted firmware, legal means, 
> etc.  (The canonical example seems to be smart phones.)

??? Why would IPv6 be more useful here?

> |> sufficient for something as utilitarian as a networking protocol
> |> suite.  We have to examine actual usage requirements.

> I understand that actual end-user requirements are not a major 
> consideration for IPv6 development.  This has been discussed before 
> and I've commented that I'm not thrilled with the decision to 
> concentrate on provider requirements,

The way something is developed and the way it is subsequently used are 
two very different things. Obviously ignoring user requirements during 
development would be a huge mistake. But once the product is there, 
there are many ways in which it may be adopted by the market place. 
End-user demand is one, lower operational costs somewhere in the chain 
is another one.

> Eventually you have to convince the end-users to use the service or it 
> will fail.  End-users have evolved a bit over the years.

End-users care about applications and services, not whether the first 4 
bits in IP packets are "0100" or "0110". If something needs IPv6 in 
order to work, and that application or service manages to install IPv6 
connecivity without bothering the user (by doing toredo on the user's 
box or 6to4 in the NAT gateway) the user won't mind.

> -We do something to satisfy the users' requirements without making 
> them resort to NAT, possibly upsetting providers who will need to 
> adjust their business models.

Since the IPv6 business model includes far fewer worms (because it's 
pretty much impossible to infect boxes by randomly trying addresses in 
IPv6) I think this will work out.

> -We do nothing special and the market supplies IPv6 NAT.  Things stay 
> pretty much as they are.

Even if IPv6 NAT becomes available, I don't think very many people will 
use it.

> -We do something radical to prevent users from employing NAT-like 
> solutions, possibly failing by succeeding if those users reject the 
> protocol.

Why would we do this?

> It is not at all apparent to me.

The trouble is that if you have stable address A and you want to 
connect to someone who has stable address B, you have no way of knowing 
whether the infrastructure in the middle supports routing packets A->B 
and B->A. So either you always prefer the stable addresses and you end 
up waiting for timeouts often, or you always prefer PA addresses and 
the advantages of stable addressing are largely lost.

> There are many ways to achieve that goal including PI space handled 
> directly at the routing level, various forms of source routing 
> including locator/identifier separation, and overlay networks.

Yes, hopefully we can get this to work.

> |ago. This was a poor design because it doesn't scale, regardless of
> |the usefulness of the functionality.
>
> This is a common but confusing generalization.  Portable address usage 
> grows linearly in the actual number of users.  It is very hard to do 
> better than this without NAT-like hacks.

CIDR has done relatively well. Could have done much better without the 
v4 address squeeze.

> Even those merely divide by a constant without changing
> the order of growth.  On the other hand, hierarchical provider-based 
> allocation consumes addresses exponentially in the number of provider 
> levels,
Not sure about this being exponential, but yes, there is more waste in 
overhead. However, this is in the addresses used, while the problem is 
the number of distinct blocks.

> assuring that there will always be an address shortage at the lowest 
> level(s).

How do you figure? If ISPs want they can request more addresses from 
the RIRs as long as they provide documentation of how those addresses 
are going to be used.

> Increasing hardware capability has taken the wind out of the memory 
> size argument, so the current fashion seems to be to consider the 
> computational load of building the table in the first place, again 
> constraining the process to work exactly as it does today.  This is a 
> harder problem to overcome by brute force, but it still has nothing to 
> do with the scalability of portable addresses themselves.

Why not?

> It just means that we can't necessarily support an arbitrary number
> of portable addresses *and* still constrain the routing process to 
> work exactly as it does today.

In what way exactly would you like to change routing?

Sure, there is lots of optimization to be had (I talked about encoding 
reachability for multihomers in bitmaps at one point) but you can't get 
around the fact that when a link goes down, you must send an update and 
every ISP has to process it. And the bigger your routing table is, the 
longer the processing takes... This scales worse than linear.

> One obvious approach (if we did want to support portable addresses) is 
> to return to a dumb network/smart host model and push the route 
> computation to the edges of the network where the available resources 
> grow with the consumers.

Sounds nice, but how is this going to work in practice?

> Routers could go back to simply forwarding packets as fast as possible 
> rather than spending lots of cycles enforcing economic policies by 
> applying complicated filters to AS paths to determine whether this or 
> that network really deserves transit service.

You need this regardless but it's moot anyway as route processing and 
packet forwarding are decoupled in fast routers today.

> It looks like you snipped a question.  Here it is in context:

Others already talked about the right vs wrong analogy, no need to 
repeat it.

Iljitsch