Subject: Re: IPv6 adoption behavior

From: Dan Lanciani <[email-masked]>
Date: Fri, 17 Oct 2003 15:34:27 -0400 (EDT)

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

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 19 Oct 2003 00:01:16 +0200

> costs and offers a reduction in the functionality that people expect 

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.

Functionality won't disappear unless people turn off IPv4, which I 
don't expect them to do. (I even get strange looks from people in IPv6 
circles when I say I want to run IPv6-only hosts for test purposes.)

> 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". But I think 
we can and should add all the missing stuff to IPv6.

> 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? Yes, there 
are some advantages regardless, but those alone aren't worth the hassle 
of upgrading the whole internet.

> actual usage requirements.

Yes. But note that this doesn't have to be the actual end-user.

> provided by NAT.

Well, there was a time when I had email without spam too. Sometimes 
progress isn't progress. 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. NAT is one of those hacks, two-faced DNS is another one.

> If you are claiming that there is just no way to deliver

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

> I did not write the above quoted text and I have no explanation for it.

I know.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Oct 2003 20:43:53 +0200

Dan,

Dan Lanciani wrote:
...
> to the typical NAT user) than the same network connected with NAT. 

By definition, facilities unavailable to a NAT user are not important
to a NAT user. What we are concerned about here is restoring the ability
to innovate that NAT has destroyed. Nobody has an incentive today to develop
innovative applications that don't work through domestic NATs. This is
a tragedy.

> But the
> and a network that is not connected to the internet at all.  

No. That's like comparing a car with only reverse gear to a car with
no engine. The correct comparison is between a car with only reverse
gear to one that can also drive forwards. Which one enjoys greater 
capability?

Now let's get back to how to resolve this with IPv6. Firstly, ISPs need to follow
the IAB and RIR recommendations to assign /48s to subscribers. Then, the IETF
(hey, this WG!) needs to approve draft-ietf-ipv6-unique-local-addr-01.txt or
something very similar. Then, the equipment vendors need to make domestic and
enterprise gateways and firewalls that handle IPv6 appropriately - supporting
autoconfig and router renumbering, blackholing draft-ietf-ipv6-unique-local-addr 
addresses by default, supporting PA addresses in the normal way. Then O'Riley 
or someone needs to publish the necessary How-To book. Actually, whoever writes
the book will find out what is still missing.

Certainly, the ADSL router I bought recently for 99 Swiss francs will never be
upgraded to support IPv6. But I'd like to think that when I buy a new one in 
~3 years, it will have IPv6 out of the factory, as well as legacy IPv4-NAT.

    Brian