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