On 13 feb 2008, at 14:44, Jonathan Rosenberg wrote:
I wrote this because of a discussion that happened during behave at
the
last IETF meeting in Vancouver. There was a presentation in the behave
working group on NAT ALG for SCTP - when run natively over IP - and I
found the entire conversation surreal.
I had the same feeling when reading your draft.
We can have a big, nasty fight about the philosophical points, but
fortunately, we don't have to, because the whole thing is based on
incorrect facts. I have never seen a consumer NAT that blocks ICMP.
I'm 98% sure that path MTU discovery black holes are NOT caused by
just NAT. Also, most of the NATs I've encountered have no problems
with non-TCP/UDP protocols (such as proto 41, IPv6-in-IP) except that
obviously only a single internal host gets to have a mapping for such
a protocol.
So apparently its not obvious to everyone that you cannot design
protocols natively ontop of IP.
You can, it just means that deployment will be harder. In many cases
that means it's a better tradeoff to encapsulate in UDP or TCP, but
that is not a universal truism.
As for the philosophical part: I have a big problem with importing
requirements from NATs and firewalls because their operation isn't
governed by any specification so it's impossible to fulfill such
requirements.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf