2009/1/9 Daniel-Constantin Mierla miconda@gmail.com:
The question could be the other way around: does anyone remember another technology that needed so many patches and workarounds :-)? Just thinking about the number of RFCs and drafts coming to complete/recommend/give usage guidelines ...
I can imagine IETF people writting RFC 3261 in their IPv6 LAN networks:
- IETF man in black 1: "humm, should I consider NAT in this specification?..."
- IETF man in black 2: "mmmmmm, but what is NAT?"
- IETF man in black 1: "AFAIK NAT is what the real world outside uses in their homes and offices, I think not all the world uses IPv6 yet... not sure..."
- IETF man in black 2: "but... if we solve NAT issue in this document... what could be writte in the future? I need to write more and more drafts and RFC, it's an obsession!"
- IETF man in black 1: "Ok, you ar right, let's ignore NAT. Hopefully noobdy will implement this specification..."
- IETF man in black 2: "Cheers"
ICE came too late, the are millions of end user devices sold out there, without it. And as "workarounds" are in place, nobody will invest now (crisis :-) ?!?!) to replace them -- only the time will obsolete them. So we still have to stick to the solutions we have now.
The good point of ICE is that it works end to end, so you can have a proxy that fixes NAT when needed ("Contact" or SDP with private IP). ICE will solve it in client side, as STUN, so proxy doesn't need to solve NAT in that case. Both methods can live together and this is cool since allows ICE implementation.