> From: Pyda Srisuresh <srisuresh@yahoo.com>
> To: Vernon Schryver <vjs@calcite.rhyolite.com>, wrec@cs.utk.edu
> Cc: nat@livingston.com, holdrege@lucent.com
> ...
> > Is there an RFC that includes the many complaints that have been made about
> > NAT boxes in the main IETF list?
>
> Not an RFC. But, a draft addressing precisely this.
> It is titled "Protocol Complications with the IP Network Address Translator".
> <draft-ietf-nat-protocol-complications-02.txt>. ...
That draft does not mention anything about the IP fragmentation problem
that we were talking about in the WREC list that provoked that comment.
Many people act on the silly superstition that a 56 Kbit/sec modem or 128
Kbit/sec ISDN link is faster with a tiny MTU. When they do that, IP
fragmentation must occur except when Path MTU works. (Do most NAT boxes
do the right things when they see the DF bit?) (That draft doesn't list
ICMP as an application whose payloads can need to be modified; consider
the packet headers in some ICMP payloads.)
NAT boxes (or perhaps "ALG" in the terms of that draft) and redirection
proxies are likely to do the wrong things when the bits in the payload
that need to be modified are not in the first IP fragment, at least unless
they do (the equivalent) of IP fragment reassembly before forwarding.
Neither kind of box can even redirect incoming IP fragments to the correct
local host, since the UDP and TCP port numbers are only in the first
fragment.
Tiny incoming IP fragments seem most likely when both TCP hosts or more
than one UDP application (there can be >2 with multicast) are using NAT
boxes. I've seen people run servers for various applications behind
NAT boxes, including HTTP, SMTP and proprietary applications.
Vernon Schryver vjs@rhyolite.com
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST