Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 24 Mar 2005 18:41:36 -0800 (PST)

--- Cullen Jennings <fluffy@xxxxxxxxx> wrote:
> 
> Ok, that proposal is concrete and I get it. Thank you.
> 
> Now the application developer that is trying to write a client that will
> work through a NAT that does this can not make any assumptions about how the
> NAT has been configured. So I don't see how behave specifying this one way
> or another makes any difference to what applications can work or not.
> 

[suresh] When applications send large chunks of data with no reverence to MTU
size, the NAT devices along the traversal will not block the fragments from
traversing. For example, aplication like NFS can work across a NAT device.

cheers,
suresh
> 
> On 3/23/05 6:30 PM, "Senthil Sivakumar" <ssenthil@xxxxxxxxx> wrote:
> 
> > My suggestion is:
> > 
> > "NATs should handle IP fragments that are seen in order and out of order.
> > When an in order fragment is seen NAT should store the L4 information of
> > the first fragment so that it can match the subsequent fragments that do
> > not carry L4 headers. No buffering of the fragments is required in case of
> > in order fragments. For out of order fragments, NAT must store the
> > fragment until the first fragment is seen. The fragments should be stored
> > for a period of N seconds before discarding them. NATs must not store more
> > than X fragments per flow and must not store more than fragments for Y
> > flows at any point of time"
> > 
> > The values of N, X and Y are to be determined by the network administrator
> > who best knows the latency of his/her network, capability of the box.
> > 
> > Senthil
> > 
> > On Wed, 23 Mar 2005, Cullen Jennings wrote:
> > 
> >> On 3/23/05 6:49 AM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:
> >> 
> >>> I believe, Requiring NATs to support IP
> >>> fragmentation will be the way to close this.
> >> 
> >> Can you provide a concise explanation of how NATs should behave on this.
> >> Then provide a sample of idea of one way that they might protect
> themselves
> >> from the using up all the memory problem. As a pointed out in my previous
> >> email, you keep asserting there is a solution to this problem. I am
> unaware
> >> of what it is so it makes me concerned to say that everyone must do
> >> something that I don't know how they can do it.
> >> 
> >> Cullen (not as chair)
> >> 
> >> 
> >> _______________________________________________
> >> Ietf-behave mailing list
> >> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> >> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 11 Apr 2005 09:21:16 -0700 (PDT)

> traversing. For example, aplication like NFS can work across a NAT device.

What size packets can the application send before it stops working because
the flow has exceeded the buffer allocated by the NAT for that flow? Of
course it is impossible to answer this question which is exactly my point.
Specifying this type of behavior, while reasonable and good, will not in
anyway help design algorithms that reliably work through NATs that have to
operate in the real world. Not knowing the size of buffers on a configured
NAT simply contributes to the non deterministic behavior of the NAT. I'm not
against implementations deciding to do the type of behavior you suggested -
I'm just pointing out that applications can not rely on the buffer size be
anything greater than zero.

Cullen - not as chair