What I took from Jonathan's draft was the sense (correct in my view)
that if we want new protocols to be successfully *deployed* in actual
production networks and communicate across the firewall (which may or
may not be doing NAT) to the public Internet, they should ideally sit
on top of either TCP or UDP.
In both small and large corporate environments, my experience has
certainly been that if you want communication to occur through the
firewall, at some point you have to talk to "the firewall people".
It may be one person or a team and they may have differing levels of
paranoia about how tight of a ruleset they have, but they are there.
And any new protocol needs to go through their box.
If you go to them and say that you need to open up TCP or UDP port
XXX to/from a certain box, they may ask you questions, but at least
they understand you. You are speaking their language.
If you go to them and say that you need to open up connections for a
new transport protocol on top of IP, they will probably look at you
like you have 3 heads. And then they'll probably ask you a lot MORE
questions. And in fact they *may not be able to do it* with whatever
firewall software they have. I have seen some firewall software that
when you are creating rules from the GUI, you only have 3 choices for
a protocol on top of IP: TCP, UDP or ICMP. Period. End of story. If
you want another transport protocol you *might* be able to do it with
some command-line hackery, but that might also potentially be beyond
the expertise level of the firewall people.
We can argue about how poorly designed that firewall software is, but
that is the reality. The deployed production environment on the
public Internet today understands that transport protocols are TCP
and UDP (with ICMP around to serve its limited purpose).
That is my take on Jonathan's point.
Want to have a successful protocol? Want it to take off and
(potentially) be adopted by millions? Use TCP or UDP as the base.
My 2 cents,
On Feb 14, 2008, at 9:19 AM, Jonathan Rosenberg wrote:
Harald Tveit Alvestrand wrote:
While I disagree with Jonathan's assertion that we should insert an
entirely useless (for all but NAT) UDP header in front of all new
protocols we design,
Well, I'd hardly characterize, "allowing it to work across the public
Internet" as a property that is useless. Statements like, "useless for
all but NAT" trivialize what the Internet has evolved into. There
everywhere. Lets accept it and design for what the Internet is, and
for the Internet as we wish it would be.
You may not like it, but its reality.
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
http://www.jdrosen.net PHONE: (408) 902-3084
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation dyork(_at_)voxeo(_dot_)com
Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com
Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com
Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com
Ietf mailing list