Andreas Fink afink@list.fink.org wrote:
On 04.03.2009, at 22:57, Norbert Bollow wrote:
Andreas Fink afink@list.fink.org wrote:
Currently, we will have a dual standard world for a while. so having IPv4 server responding with IPv4/Ipv6 information is what we are going to see for a long long while. Nobody says you should NOT have IPv4. Just not only. I see the future as IPv4->NAT->limited, IPv6->Native.
How do you (reliably) talk with IPv4-only hosts via the internet when you're on an (IPv6 natively connected) IPv6-only ethernet?
1st: who says its IPv6 ONLY ethernet? IPv4 can and should stay. Maybe through crappy NAT or proxy. Maybe only to assign DNS ;-)
Maybe it hasn't been seriously raised on this list before, but I think that the "IPv6 ONLY ethernet" question is central to the discussion:
Unless there is a good solution that allows end user organizations (e.g. companies of any size) to run IPv6 only on some of their network segments, it will mean just additional pain for little or no gain to run IPv6 in addition to IPv4. This is both with regard to the aspect of cost and also from the viewpoint of complexity management from the perspective of the organization's IT manager.
It's in theory possible to upgrade all networks to dual-stack, yes, but as long as there are no sufficiently strong incentives to use IPv6 for production purposes, IPv6 will continue to be used for ping traffic almost exclusively. Under these conditions, I don't see how I could with good conscience recommend to my customers to make any IPv6 related investments besides ensuring that all routers which are bought from now on should be be dual-stack capable and performace-tested with respect to IPv6 also and not just with respect to IPv4.
In summary, I don't think that the necessary incentives are in place so far to really get the IPv6 transition going....
Hence my call to revive the Swiss IPv6 Task Force.
2nd: IPv6 maps IPv4 addresses into a specific IPv6 prefix. So if you talk purely IPv6, you can address an IPv4 host by using the ::ffff: prefix.
As pointed out by Jeroen, IETF is deprecating this, but apart from that, I'd agree that it's a possible approach. Of course you'd still have to arrange for a NAT-PT (Network Address Translator - IPv6/IPv4 Protocol Translator) box to be set up and operated somewhere either on the end user organisation's premises (requiring to buy both IPv4 and IPv6 connectivity) or at the ISP (by means of an explicit service level agreement for the NAT-PT service). (Certainly I wouldn't think of just sending packets with ::ffff: prefix out on the IPv6 internet and expect that to miraculously work reliably, somehow!) Still this approach has all the drawbacks of NAT, and in addition it's likely to be less reliable than plain old IPv4 NAT, because NAT-PT boxes are less likely than plain old NAT boxes to have been tested under conditions similar to actual production use.
Even besides the issue that using a prefix which is (no longer) supposed to be used on the wire is IMO too brittle for production use (due to the risk of things getting broken by some software update somewhere):
How can any approach of this type be better, at any point in time in the foreseeable future, than using plain old IPv4 NAT together with kludges to make authorized P2P applications etc work?
Are there any other possible solutions which do not have the disadvantages of NAT as well as the disadvantage of newness?
Greetings, Norbert