First, I do agree that for operation through NATs, and even Firewalls, having the UDP header has been demonstrated to significantly simplify things, and is probably sensible. (My earlier notes were prompted by a tone that said ~therefore all work we do should be over UDP or TCP. Always.~) Lets not get carried away here though. That does not solve the problem of operating through NATs. I know that most folks in this conversation are well aware of this. But the tone has started to sound like "do this and all will be well." Which isn't even remotely the case. 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. Yours, Joel M. Halpern Jonathan Rosenberg wrote: > > Spencer Dawkins wrote: >>> Mind you, I'm not saying that protocols should always use a UDP >>> shim layer. But I think the tradeoffs in favor of doing so are a bit >>> stronger >>> than you seem to think. >> This is my chance to act the naif for Valentine's Day, but ... >> >> I agree that UDP shims improve your ability to get through a NAT in the >> short term. However (and especially given Melinda pointing out that NATs >> impede connectivity for technical reasons, but firewalls impede connectivity >> for policy reasons), we need to recognize that this is an arms race. > > Thats why you need to separate it. > > Running ontop of UDP and TCP means that your protocol can function > through a NAT which exists for the purpose of NAT, regardless of > firewall and administrative policy. And it means its in a format that > your firewall vendor COULD manage policy for. It removes the TECHNICAL > barriers to working on the Internet, leaving just the POLICY barriers. > > Now, that doesn't address the problem of how we do a better job of > managing those policy barriers. But one step at a time. > > -Jonathan R. > > > _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf