Subject: [Ietf-behave] New draft on UDP unicast behavior

From: Cullen Jennings <[email-masked]>
Date: Sun, 17 Oct 2004 04:48:05 -0700 (PDT)

Until it gets posted, you can find it at

http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-00.ht
ml

or

http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-00.tx
t

---

From: Senthil Sivakumar <[email-masked]>
Date: Mon, 18 Oct 2004 14:29:37 -0700 (PDT)

Some comments.

A large portion of this document seems to talk about the generic behavior
of NAT and could very well be extended to TCP (or other layer 4 protocols
that have a L4 identifier).
Any specific reasons to restrict it to UDP only?

Section 3.1 
There is another flavor of NAT behavior in the IP address pooling
case.
NATs would overload on one address for several internal clients whenever
possible. But the NAT uses a different address for for the same host
applications that do not have port information. (DNS for example). This
is neither an arbitrary behavior nor a strict behavior. It is somewhat
?adaptive?, IMO. 

Section 6:
Is different ALG behaviors based on UDP is out of scope?

General comment:
NATs have different behavior based on what it is configured to do. So the
port
preservation and filtering 

Section 11:

General comments.

Are the requirements mentioned in this section the default behavior of
NATs? I don?t think that would be acceptable to all vendors. The default
behavior is very much dependent on a particular configuration of NAT.
Changing existing behavior is always a challenge, so you could say some
thing like ?a NAT should be able to behave in the mode specified by
IETF?, where the vendors could still preserve their current behavior and
provide the new behavior based on what mode is turned on. I think it
could be argued that it would again make NATs 
non- deterministic,  but that would give NAT vendors a motivation to
follow the 
new behavior without having to drastically change the existing behavior.

Specific ones.
REQ-2b: A NAT MUST NOT have an "IP address pooling" behavior
of
         "No".
I could not figure out what the ?IP address pooling
behavior of ?No? is. Did you mean to say ?arbitrary? ?

REQ-3c: If the NAT changes the source port, it MUST NOT
         allocate the new port
from within the range of 0-1023.

We tried this and atleast one application (rcp) is broken when we do
this, where the server expects the source port to be in the low
range.  So there may be application dependencies with this behavior.

REQ-5: A dynamic NAT UDP binding timer MUST NOT expire in less
      than 2 minutes.

What do you mean by dynamic NAT UDP binding? There are applications that
dictate how long the binding stays and what happens if the application?s
timeout is less than 2 minutes. 

REQ-10: A NAT MUST have the capability to turn off individually
      all ALGs it supports, except for DNS and
IPsec.

Can we say that all the ALG?s working in the well known port range should
be on by default? And all ALG?s listening on reserved ports and ephemeral
ports should be off by default.

         REQ-10a: Any NAT ALG for
SIP MUST be turned off by default.

Section 12.

General Comments. 

NATs can store the out-of-order fragments for a period of time until the
first fragment arrives. This timeout could be a tunable one. I would like
to see that this document recommending the handling out-of-order
fragments. 

Minor ones:

REQ-13 and REQ-13: should be Req-13 and Req-14.

Senthil

At 07:48 AM 10/17/2004 -0400, Cullen Jennings wrote:

or

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave