This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] Implications of NAT/NAT64 and similar
- Previous message (by thread): [ipv6-wg] Implications of NAT/NAT64 and similar
- Next message (by thread): [ipv6-wg] Implications of NAT/NAT64 and similar (was: Re: IPv6 only as default for next meeting)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Benedikt Stockebrand
bs at stepladder-it.com
Sun May 24 13:29:09 CEST 2015
Hi Silvia and list, Silvia Hagen <silvia.hagen at sunny.ch> writes: > Transition mechanisms have the attribute of being transitional by > definition. So they bridge gaps. That is exactly what NAT was > originally designed for - bridge a gap until real solution is at hand. > [...] yes, but they also have another effect: They make people believe that the problem is solved, often leading to a situation where these stopgap measures don't work any longer and the pressure to fix the problem is *really* bad. Or, in a different context: As long as the painkillers work, why should I go to the dentist? Only when the workaround is more painful than the problem it solves, then people start to move. We see that with DS-Lite, which is why I called it so useful at the RIPE meeting in Amsterdam: To the ISPs and the content providers, and increasingly to the enterprises too, it is simply less painful to go server side dual-stack than deal with the collateral damage caused by IPv4-only on their side and DS-Lite on their users. > So let's hope we learned from the NAT issue Seriously, I doubt that; this behaviour is too deeply entrenched in peoples minds. And while we're both making a living out of IPv6, it's still a niche market for people like us; if people had learned, then we'd be drowning in project offers. > We live in a free world and the Internet is VERY diverse. > What is good for the ones is bad for others. Fully agree on that. And it's rather difficult to come up with ideas or approaches that won't cause significant problems for others. But that's exactly why I point out the problems NAT causes to other people. > I do not believe in IETF or whoever else dictating the market how to > do it. Hmm, I guess there are a number of people at the IETF who'd be quite seriously offended by that statement, but anyway: One of the most fundamental goals of the Internet and the technologies used there is interoperability. I still remember how Compuserve and AOL and MSN and various others tried to establish their proprietary internetworking products, and people eventually opted for the Internet largely because of its interoperability. The role of the IETF is to ensure that specifications (not standards by the way, but that's yet another issue:-) support this interoperation. > I think we should offer different transitional solutions solving > different issues and let the actors in the market decide, what > combination works best for them. Yes, but: If the "market decides" then there's a good chance that people will sacrifice that interoperability for their own advantage. There are some people who benefit from full-blown NAT66, but others will then have to pay the price (STUN, reduced reliability, increased operational expenses, extra hardware, ...). One of the problems with transitional solutions, aside from delaying the inevitable until it really hurts, and always lasting forever, is that each increases complexity. And considering how difficult it is to recall those solutions when once made available. Which leads back to the extension header issue... Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
- Previous message (by thread): [ipv6-wg] Implications of NAT/NAT64 and similar
- Next message (by thread): [ipv6-wg] Implications of NAT/NAT64 and similar (was: Re: IPv6 only as default for next meeting)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]