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@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf