Le Thursday 14 February 2008 12:05:37 ext Iljitsch van Beijnum, vous avez
écrit :
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. I similarly have
yet to see a NAT devices have not impeded IGMP, OSPF, or PIM very much
either. But I think that is totally beyond the point of Jonathan's draft.
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.
Again, IPv6-in-IP (proto-41), as well as IPIP and GRE are tunneling protocols,
not really transport protocols. They are typically manually provisioned, so
that they work. Then again, some people do (have to) use UDP tunneling
instead (think of Teredo and ESP-in-UDP); also 6to4 does not work through
many NATs.
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.
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?
I would argue that Jonathan's document does not go far enough. There are quite
severe limitations as to the use of TCP through NATs: the passive end cannot
be NAT'ed.
UDP mostly work, except it is not reliable NAT-to-NAT, and it is unsuitable
for battery-powered devices, as most NATs and firewalls have too short
timeouts for UDP flows.
And then comes firewalls, and proxies. So as was already mentioned, one could
argue the waist hourglass is HTTP and HTTP/SSL, and this discussion is
irrelevant.
--
Rémi Denis-Courmont
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf