--- Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
> > 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.
>
I dont know the exact problem you were talking about in the WREC list.
But, IP fragmentation problem is listed as one of known NAT limitations
in section 6.3 of <draft-ietf-nat-traditional-03.txt> as follows.
We will add a note at the end of section-1 in the Complications draft,
refering readers to known NAT limitations listed in RFC 2663 and the
traditional-nat draft.
6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup
Translation of outbound TCP/UDP fragments (i.e., those originating
from private hosts) in NAPT setup are doomed to fail. The reason is
as follows. Only the first fragment contains the TCP/UDP header that
would be necessary to associate the packet to a session for
translation purposes. Subsequent fragments do not contain TCP/UDP
port information, but simply carry the same fragmentation identifier
specified in the first fragment. Say, two private hosts originated
fragmented TCP/UDP packets to the same destination host. And, they
happened to use the same fragmentation identifier. When the
target host receives the two unrelated datagrams, carrying same
fragmentation id, and from the same assigned host address, it
is unable to determine which of the two sessions the datagrams
belong to. Consequently, both sessions will be corrupted.
> 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
What excatly is your concern with NAT boxes and DF bit? Please elaborate.
> ICMP as an application whose payloads can need to be modified; consider
> the packet headers in some ICMP payloads.)
>
Agreed. This is part of NAT operation described in traditional-nat draft.
I dont believe, this belongs in "NAT complications" draft.
> NAT boxes (or perhaps "ALG" in the terms of that draft) and redirection
NAT boxes are not same as ALGs. NAT boxes are those that implement a
NAT type (typically NAPT or Basic-NAT, as described RFC 2663) and some
number of ALGs.
> 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.
>
You will need an ALG to do any kind of modification to the payload.
What is the problem with IP fragments here?
> 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.
>
When IP fragments are directed to the NAT box, NAT will need to
reassemble the fragments into a single MTU prior to translation.
And, NAT devices do just that.
> 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.
>
I believe, this is addressed in my previous comment already.
>
> Vernon Schryver vjs@rhyolite.com
cheers,
suresh
__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST