Rémi, I agree with the sentiment in your comments and hope other folks on the list would provide their comments as well. > what about having this balkanization of NAT traversal solutions for > each application protocol separately? > Maybe NAT traversal does not belong in MMUSIC as Lars Eggert has mentioned? Thanks, Henry -----Original Message----- From: Rémi Denis-Courmont [mailto:remi.denis-courmont@xxxxxxxxx] Sent: Wednesday, February 27, 2008 2:16 AM To: Henry Sinnreich Cc: Magnus Westerlund; Cullen Jennings; Peterson, Jon; Gonzalo Camarillo; Jeff Goldberg (jgoldber); Philip Matthews; Lars Eggert; mmusic@xxxxxxxx Subject: Re: [MMUSIC] The fragementation of NAT traversal per application is unfortunate Le Tuesday 26 February 2008 22:35:52 ext Henry Sinnreich, vous avez écrit : > It is interesting to see doubting the support from Microsoft and that > openVPN has the disadvantage of encryption :-) > > But what about having this balkanization of NAT traversal solutions for > each application protocol separately? I agree with you that re-inventing NAT traversal for "one's own" protocol seems to be a trend in IETF, not a very great one. I would however point out that HIP is not *fundamentally* a NAT traversal mechanism, rather a new addressing architecture for the Internet, and OpenVPN is well, a VPN protocol, not a NAT traversal protocol. Because of this, their NAT traversal schemas simply cannot re-used. That's why I like Teredo/RFC4380 and non-SIP ICE a lot better. These are *only* NAT traversal layers, and both of them are already widely deployed: RFC4380 is in all recent Windows boxes, and non-SIP ICE is basically the same as Jingle in GoogleTalk. RFC4380 provides the "transport-agnostic" always-on tunneling schema which you keep asking for: you can run TCP unencumbered or any fancier transport on it. Non-SIP ICE is a simpler solution that can be used when you only need an "on-demand" "datagram" carrier through NATs. Of course, you could also port OpenVPN on top of non-SIP ICE or so, but that only keeps the balkanization going. > Maybe NAT traversal does not belong in MMUSIC as Lars Eggert has mentioned? Quite possibly. It sounds very much like a transport issue, rather than a RAI (neither INT) one to me. > I also tend to see it as transport issue that has to work transparently for > all application layer protocols. HIP could do it, unless there are better > solutions. In my humble opinion, a better idea is to not reinvent NAT traversal specially for HIP, but use an existing schema instead. -- Rémi Denis-Courmont _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf