On a number of residential devices for which we (Ubicom)
deliver the
core software we've just upped our timeouts to 5 minutes
for UDP and 4
minutes for non-synchronized TCP states from the 2 minutes
we used to
use (we did this back in January). It does lead to more
sessions being
tracked but makes a number of P2P-based apps behave better
(we see far
fewer firewall messages about rejected packets and those
that we do see
now generally come from other NATs that incorrectly
translated ICMP
payloads or remapped ports mid-session). This affects
routers from
several vendors (one you queried and several smaller ones
you didn't).
Incidently I'd note that there are quite a few different
codebases
around in the residential router market and some have very
different
implementations of their NAT. It't not at all unusual to
find that
different products shipped by the same OEM have different
codebases and
quite different behaviour.
Regards,
Dave
* -----Original Message-----
* From: ietf-behave-bounces list.sipfoundry.org
* [mailto:ietf-behave-bounceslist.sipfoundry.org] On
Behalf Of
* Pyda Srisuresh
* Sent: 25 April 2006 15:07
* To: Cullen Jennings; Francois Audet; Magnus Westerlund;
Dan Wing
* Cc: Behave
* Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD
evalution
* comments ondraft-ietf-behave-nat-udp-05)
*
*
* Thank you for the feedback from Linksys. What is the UDP
* timeout used on the LinkSys, NetGear, D-Link and other
* residential NAT devices? What are the bounds to the limits
* they are willing to accept?
*
* There are a number of enterprise/data-center devices that
* embed NAT functioanlity within. They have resource
* constraints that would be put to test when the timeout is
* made very long. Not to mention the usage constraints that
* Ariel mentioned. It woudl be good to consider their
feedback
* as well before mandating.
*
* Regards,
* suresh
*
* --- Cullen Jennings <fluffycisco.com> wrote:
*
* >
* > I would like to make a comment about low end NAT
vendors. Most
* > comments I make are just my opinion but this morning
I
* contacted the
* > relevant engineers and Linksys and am passing on the
* information from
* > Linksys. I believe and support all this information.
* >
* > Linksys is by far and away the number one NAT vendors
when
* measured by
* > number of units shipped. None of the Linksys NATs
have a time out
* > value as low as one minute for this timer. There is
no problem with
* > running out of ports on any of the residnetintial
NATs and
* that is not
* > a concern. Even with heavy P2P applications, port
depletion
* is not an
* > issue. The memory to store state for a large number
ports is a very
* > small portion of the total memory budget for the
devices
* and not an issue.
* >
* > In conversations with Netgear and DLink, I believe
they have very
* > similar beliefs on all this - basically all the low
end NAT
* > manufactures are using very similar code bases on
nearly identical
* > hardware so it is not surprising that if this is not
a
* problem for any of them.
* >
* > I don't in anyway believe that a 1 minute time out
will be
* useful for
* > the residential style NATs. I don't know anyone
involved
* with building
* > these style NATs that believes that 1 minute is
needed -
* there might
* > be someone but I have not seen them post to the list
or talk to me.
* >
* > I did not go and discuss this issue with the people
that build high
* > end enterprise style NATs at Cisco.
* >
* > This is a tradeoff between running out of ports on
the NAT, and
* > running out of bandwidth on the link and processing
keep alive
* > transactions on the servers and batter life on mobile
clients. Many
* > people have expressed many concerns about having this
* number too low.
* >
* > Cullen <with my individual contributor hat on and
passing
* on data from
* > Linksys>
* >
* >
* > On 4/23/06 8:13 PM, "Pyda Srisuresh"
<srisureshyahoo.com> wrote:
* >
* > >
* > >
* > > --- Francois Audet <audetnortel.com> wrote:
* > > ...
* > >>>>> 5. Section 4.3: REQ-5:
* > >>>>> "A NAT UDP mapping
timer MUST NOT expire in less
* than 1 minute,
* > >>>>> unless REQ-5a applies.
* > >>>>> a) A NAT MAY have UDP
mapping timers that have
* much shorter
* > >>>>> timers, but only for
specific ports in the
* > >>> well-known port
* > >>>>> range (i.e., ports
0-1023) where the IANA-
* > >>> registered protocol
* > >>>>> is strictly a
request/response protocol, such as
* > >>> for example
* > >>>>> DNS over UDP/53.
* > >>>>> b) The value of the NAT
UDP mapping timer MAY be
* > >>> configurable.
* > >>>>> c) A default value of 5
minutes for the NAT UDP
* > >>> mapping timer is
* > >>>>> RECOMMENDED."
* > >>
* > >> We have been trying to balance our
requirement for timer values
* > >> between what makes sense for
"residential-grade" NATs
* versus large
* > >> Enterprise NATs (who happens to be Firewall
at the same time).
* > >>
* > >> The larger timers make sense for the
residential-grade NATs. Req
* > >> 5-c is useful for residential-grade NATs,
because often, the
* > >> manufacturers are very amiable to a
recommended default.
* > >>
* > >> What we have found however is that the
Enterprise NAT
* vendors where
* > >> quite uncomfortable with long timers. The
change from "2
* minutes"
* > >> to "1 minute" for the minimum
was a result of request from
* > >> Enterprise NAT vendors. We are a bit worried
that if the
* timer is
* > >> too long, they will simply ignore the
requirement.
* > >> Req 5a was introduced to allow for
optimizations that are very
* > >> common for large Enterprise NATs.
* > >>
* > >> So, I think we have three options:
* > >> a - Keep the original value (before -05),
which was 2 minutes.
* > >> b - Keep the lower limit from the -05 draft,
which is 1
* minute c -
* > >> Use 3 minutes, as per Magnus and Cullen's
dialog
* > >>
* > >> Personally, I think that we should revert to
what we had
* before -05
* > >> which is the 2 minutes. It seems to me that
we circled
* the argument
* > >> many times now, and that it is the best
compromise.
* > >>
* > >> But I'm happy with any of those values.
* > >>
* > > [suresh] I agree, makinng the timers long can be
problematic to a
* > > number of NAT vendors, especially those that
make low-end NAT
* > > devices with limited resources.
* > > NAT vendors fine tune these timeouts to suit
their customer
* > > environmets. If IETF mandates the timeouts to be
long,
* the vendors
* > > could run into support problems they had not not
* anticipated as NATs run out of resources quickly.
* > > IETF will not be there to help them with the
support issues.
* > >
* > > My vote is to keep the timer at 1 minute. I
believe,
* setting this to
* > > more
* > than
* > > 2 minutes could potentially invite unknown
support issues. Many
* > > vendor
* > might
* > > in turn choose not to adapt the madanted
timeouts. My 2c.
* > >
* > > regards,
* > > suresh
* >
*
*
*
* _______________________________________________
* Ietf-behave mailing list
* Ietf-behavelist.sipfoundry.org
* https://list.sipfoundry.org/mailman/listinfo/ietf-behave
*
*
************************************************************
*****************
**UPDATE 4/12/06***
Ubicom is Moving!
Effective May 1st, 2006 our new address and phone number
will be:
Ubicom, Inc.
510 N. Pastoria Ave
Sunnyvale, CA 94085
>>>>NEW NUMBER: (408) 789-2200 - Main
(408) 739-2427 - Fax
www.ubicom.com
************************************************************
******************
_______________________________________________
Ietf-behave mailing list
Ietf-behavelist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/ietf-behave
|