Iljitsch van Beijnum <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
