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