Joel M. Halpern wrote:
...
I think that the key question that Jonathan's draft drives us
towards is whether work like the SCTP / UDP draft Dan Wing pointed
out needs to get more attention. And soon. It does seem to me that
being able to run the applications which drove SCTP and DCCP over
NATs is probably important. And Jonathan (and others) observation
that if the traffic isn't TCP or UDP it frequently won't get through
NATs does seem to match observed reality.
I didn't provide a pointer to that SCTP/UDP draft to the list, and I
noticed that just today a new DCCP/UDP draft was announced. The
two drafts are:
"UDP Encapsulation of SCTP Packets"
http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps
"Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT
Traversal (DCCP-NAT)"
http://tools.ietf.org/html/draft-phelan-dccp-natencap
What seems useful is a mechanism where the UDP encapsulation can be
attempted and the native (non-UDP encapsulted) protocol can be
attempted. In this way, the protocol can work through a skinny
hourglass (by running over UDP), yet if the path is unimpeded by
firewalls/NATs/proxies then the (more efficient) native encapsulation
can be used.
Where DNS can be used as the rendezvous protocol, DNS SRV might
provide a way to accomplish such a thing, where you could learn that
there is a UDP-encapsulated port and a native (non-UDP encapsulation)
protocol to a host. The application and/or the underlying SCTP/DCCP
stack could try both, in some agreed-upon order and with agreed-upon
backoff mechanisms.
Such a mechanism is what ICE, draft-ietf-mmusic-ice, performs in its
attempts to get v4, v6, UDP, or TCP connectivity. ICE needs a
rendezvous protocol that includes an offer/answer exchange, such as
SIP, RTSP 2.0, or XMPP.
-d
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf