"Jeroen Massar" <[EMAIL PROTECTED]> wrote:
|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.
Exactly. It isn't NAT but the address limitation that causes the problem.
|Basically that boils to:
|
|ISP's should sell bandwidth *NOT* IP space.
Sure. I've been saying that for years. IMHO it is one of the great tragedies
of IPv6 that we failed to separate allocation of addresses from provision of
bandwidth. As long as one entity controls both for a given customer they will
make the addresses part of the price model.
|> |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. :)
|
|It is perfectly interresting as [...]
Again, it is not very interesting for the purposes of determining whether
IPv6 can _replace_ IPv4+NAT as suggested.
|> 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.
Sure there is if the user has no access to the *local* end which is
embedded in the tamper-resistant firmware of a smart phone. My point
was that this is a context where you can force the user to pay per
address since he cannot install NAT within the phone.
|> 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)
The end-user has tasted the power of internetworking. I don't think
you will make him forget that easily. But then I may be wrong. It
is said that nobody ever lost money underestimating the intelligence
of the consumer. Or something like that.
|> 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.
This is just another variation of the "PI doesn't scale" argument. The
administration angle is kind of funny, though. Isn't it amazing how the
registries manage to "administer" as many domain names as anybody cares to
pay for? I guess it's much harder to keep a list of numbers than to keep
a list of names...
|> 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.
Of course, that's not quite true. People keep trying to project onto NAT the
problems caused by the provider's limitation of a single IP address. Think
of NAT as spreading out the capabilities of the single supplied public address
among several machines. If your single public address was capable of running
your P2P application then likely NAT will let you run that same application on
one machine behind the translator. The fact that you can't run the application
on *all* the machines behind the translator is not the fault of NAT, it's the
fault of your provider for giving you only one public address. NAT cannot
magically create unique public addresses out of the ether, but neither does
it destroy in a wholesale manner the functionality of the one you have. Yet
because of the complicated and incredibly ugly *mechanics* of NAT it is bound
to screw up something and/or require painful manual configuration to get a
particular application to work behind the translator. On the other hand, it
is a testament to how well NAT approximates a routed network connection that
people start blaming it for things that are completely beyond its control.
|> 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 :)
I agree that that is even better:
(NAT connected network with IPv6 tunnel) >
(NAT connected network) > (unconnected network)
However, I suspect that you will find that if/when IPv6 access becomes
valuable to the typical customer, your tunnel broker will start charging
you for addresses just as your local ISP would.
Dan Lanciani
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
