Subject: RE: IPv6 adoption behavior

From: Dan Lanciani <[email-masked]>
Date: Fri, 17 Oct 2003 00:29:42 -0400 (EDT)

"Tony Hain" <[email-masked]> wrote:

|Dan Lanciani wrote:
|> ... Attempting to pigeonhole
|> each aspect of that isolation (and offer limited solutions) encourages a
|> divide-and-sweep-under-the-rug attack.
|
|Recent evidence around the IETF supports this claim, but in the real world
|where NAT is seen as the single solution to all the problems, we need to
|break them down to show the alternative solutions to each.

That's easier said than done.  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.

We all know how the NAT story was supposed to play out.  The unwashed masses
were going to struggle along in constant and terrible pain from the horrible
effects of ambiguous addressing.  Every day they would pray for the next
generation of IP to descend from on high and save them.  Because the pain of
NAT had been so great, no cost (one-time or recurring) would be too high to
pay for the privilege of renting multiple global addresses once again.

But something went wrong.  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. They could do this without
having a network manager to go negotiate with the ISP for a few more expensive
addresses.  They could do this without talking to the ISP at all.  And the
networks worked.  The machines could talk to each other without interference
from the ISP and they could also talk to the internet when the ISP was up.  The
ISP could in fact be replaced with few repercussions for the user's machines.
There was a brief period when people pondered why they had to set ftp's passive
mode, but it quickly became the default.  This may not be the way the net worked
in the good old days (for those who even remembered when users were allowed to
own their own addresses) but it was darn close:  a lot closer than the pre-NAT
PA situation, and a lot closer than the proposed IPv6 "solution" as currently
envisioned.

Network consumers are not fools.  They may not understand the details, but they
understand the functionality that they have at a high level.  They are not going
to give it up easily, and repeated assertions that they are suffering in great
pain (the cure being to abandon NAT) will not be convincing.  We need to offer
them something better, where better is a true superset.  I had high hopes that
IPv6 could be that superset, but over the years I've seen it reduced to IPv4
with more address bits.  Or worse.  The internet is about interconnecting
networks, not about turning the operation of those networks into a for-pay
service of an external provider cloud.

|> |Concerns about tracability are dealt with by RFC 3041 addresses.
|>
|> I have my doubts about this; it may backfire.  If you tell your
|> ISP that you
|> need more privacy it may be happy to oblige by increasing the
|> frequency with
|> which your single valid address changes.  Be careful what you wish for.
|
|If a provider is going to offer me a single address, I will insist on a
|globally routable IPv4 one,

It would be interesting to take a poll of people whose ISPs do not offer
a globally routable IPv4 address to see what happened when they insisted
on one.  Even if they got it, it seems a roundabout way to assure IPv6
privacy...

|> |That leaves address stability for external application use,
|>
|> It also leaves address rental cost, and limitations on number of addresses
|> available regardless of what you may be willing to pay (at least within a
|> class of service).
|
|Current policies are fed by the resource scarcity, which over the short term
|is artifical, but over the long term is real. We haven't gotten the correct
|version at the nav6tf web site yet, but a paper there 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. Taking that down to current practice of
|85% more than triples the number of /8's required to well over 1300. And
|again, that is only to provide one address to 20% of the population in those
|countries that don't already have that many.
|
|Take scarcity off the table, and it will be difficult to maintain per
|address costs if there is any competition in the environment.

I disagree completely.  ISPs use address count as a surrogate for bandwidth
measurement, and they they want you to pay per machine (just as the cell phone
companies want you to pay per phone even if you use only one at a time).  It's
a business model and it isn't going to change with IPv6.  Besides, I want to be
able to connect multiple machines even in areas with only a single uncompetitive
ISP.  I want a protocol solution that works regardless of the market dynamics.

But I think you've just shown why we will fail.  Other people have equally
(un)convincing hand-waving arguments that ISPs will generously give us stable
IPv6 prefixes even if they currently churn our IPv4 address daily.  Clearly
then we do not need site-locals or anything to replace them.  As long as you
are willing to dismiss the aspects of the problem that you don't care about
(or leave them to the supposedly-competitive market) you will never find the
unanimity to tackle the problem as a whole.

|> It probably leaves other things that I am forgetting.  I
|> think this is a good illustration of the pigeonhole pitfall.  If you fail
|> to address any one aspect of isolation and that aspect is
|> important to enough
|> people, a NAT solution will appear to fill the void.  That
|> solution will likely
|> include all the "bad" features of NAT as well simply because it's easy and
|> people already understand the model.
|
|I agree, so we need to be documenting all the cases we can find for why
|network managers will demand isolation from SP provided addresses.

Why bother?  You've already dismissed a critical requirement, and one which
users understand NAT to accommodate perfectly.  No matter what other problems
you solve, the battle is lost by a single omission.

|> The core issue appears to be that any comprehensive solution to
|> the isolation
|> problem would disenfranchise the address allocation hierarchy
|> (just as simple
|> PI allocation would), and we aren't prepared to do that.
|
|I agree that some approaches will disenfranchise some historical
|institutions, but I don't think that is what is holding us back.

I have yet to find any other explanation for why we discard relatively
simple (yet comprehensive) solutions while spending time on extremely
difficult and incomplete approaches like transparent renumbering.

				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: Fri, 17 Oct 2003 13:25:38 +0200

On 17 okt 2003, at 6:29, Dan Lanciani wrote:

> NAT is stiff competition--and it is the

So what are you saying?

That we should give up on IPv6 because IPv4 w/NAT is so great that we 
don't need it?

Or that we should add NAT to IPv6?

I'm not buying. IPv6 is superior to IPv4 (with and without NAT) in many 
ways. The trouble with networking has always been that even poorly 
designed networks can work well so there is little incentive to do it 
right.

> NAT was not as painful as it was supposed to be.
> 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. Application builders are bending over 
backwards to work within those limits, which costs time and money and 
isn't 100% successful.

But this discussion is moot as there is no requirement that IETF 
protocols are adopted by 100% of all internet-connected systems.

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

> |will show that we will
> |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?