On 14 feb 2008, at 12:03, Rémi Denis-Courmont wrote:
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.
ICMP is not a transport protocol. It is a control protocol.
Again, IPv6-in-IP (proto-41), as well as IPIP and GRE are tunneling
protocols,
Well, Jonathan used any non-TCP, non-UDP and ICMP in particular not
being allowed through NAT as the underpinning for his reasoning. That
point is simply incorrect and therefore the whole line of reasoning is
built on quicksand.
also 6to4 does not work through many NATs.
The reason that as a rule, you can't do 6to4 through NAT is because
you don't know your 6to4 prefix if you don't know your real IPv4
address. Whether the packets make it through is a different question.
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.
No no no. I know five IETF transport protocols: the 2 old ones (UDP
and TCP),
and the 3 "new" ones (SCTP, UDP-Lite, DCCP). As a matter of fact,
only the
old ones work through NATs *at* *all*.
SCTP multi-homing is a SCTP-specific problem that is pretty much
incompatible
with how common NATs work.
DCCP connection model is very similar to that of TCP. And UDP-Lite is
essentially the same as plain UDP. Still, neither of them work
through NATs
at all. When changing the IP address, the transport layer checksum
is broken.
Hence NATs need to be specifically upgraded to handle DCCP and UDP-
Lite.
Or, when designing new protocols, the checksum is calculated in such a
way that address translation isn't a problem. Or the implementation
discovers the outer IPv4 address and adjusts its checksum calculation
accordingly. This doesn't make all non-TCP/UDP protocols impossible.
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.
What about the BEHAVE working group?
What about them? I haven't read the mailinglist for some time, but it
sure seems there are some weird things going on there.
So as was already mentioned, one could
argue the waist hourglass is HTTP and HTTP/SSL, and this discussion is
irrelevant.
Many NATs and firewalls block incoming TCP sessions or unexpected UDP
packets. So if we use the logic "only stuff that works on 100% of all
hosts connected to the internet is relevant" then EVERYTHING is
irrelevant.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf