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(_dot_)denis-courmont(_at_)nokia(_dot_)com]
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(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf