--- Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
> > From: Pyda Srisuresh <srisuresh@yahoo.com>
> > To: Vernon Schryver <vjs@calcite.rhyolite.com>, nat@livingston.com,
> > wrec@cs.utk.edu
> > Cc: holdrege@lucent.com, srisuresh@yahoo.com
>
> > ...
> > 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.
>
> draft-ietf-nat-traditional-03.txt is at neither ftp.isi.edu nor
> http://www.ietf.org/internet-drafts
>
Well, the following URL still works for me.
http://www.ietf.org/internet-drafts/draft-ietf-nat-traditional-03.txt
> but please don't send me a private copy. I've intentionally not
> subscribed to nat@livingston.com. If you think the document says enough
> about IP fragmentation, then fine.
>
Will do.
>
> > ...
> > What excatly is your concern with NAT boxes and DF bit? Please elaborate.
>
> My guess is that many NAT boxes choose to pretend to be too-smart-by-half
> bridges instead of routers and ignore the DF bit.
>
>
I dont think so. I believe, NAT boxes do behave like standard routers
with regard to DF bit.
> > > 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.
>
> If I were writing a document listing complications of NAT, I would
> include at least a reference to descriptions of other serious problem.
>
>
Will do.
> > > 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.
>
> I think I now understand the very positive, even pollyannaish tone
> of the document. And note again, that while I think third party
> redirection proxies are somewhere between criminal and completely
> unethical and immoral, I think NAT boxes have been and will continue
> for at least a while to be better than any of the (un)available
> alternatives, and so one might think my prejudices would cause me
> to not sensitive to a overly rosey pictures.
>
>
> > ...
> > > 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.
>
> They should, but do most?
>
I believe, they do. As recipients of end-node packets, they are required
to confirm to RFC 1122 ("Requirements for Internet Hosts -- Communication
Layers"). Beyond this, I cannot comment further on existing NAT
implementations. I am not aware of DF-bit violation problems, specifically
with NAT routers.
> Public experience with somewhat related boxes is relevant. It was always
> completely obvious that an FDDI-Ethernet bridge must act like a router
> for large IP/FDDI packets, and generate IP fragments if allowed by the DF
> bit and send ICMP errors if not. However, for years more than one vendor
> of such bridges insisted in public simply droppping large FDDI frames was
> perfectly fine, and that FDDI hosts should just know enough to not use
> the FDDI MTU. The best FDDI-Ethernet bridges would IP fragment (and at
> wire speed), but none sent both honored the DF bit and sent ICMP errors.
>
Vernon - If there exists a large-scale problem in the market with regard to
violation of DF bit semantics by NAT routers, I agree, we ought to
document that, just as much as we ought to document such a problem with
regard to FDDI-ethernet bridges or even some routers for that matter.
But, I am not aware of such a large-scale problem with NAT routers.
>
> Vernon Schryver vjs@rhyolite.com
>
regards,
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