Subject: [Ietf-behave] TCP behavior

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Oct 2004 06:59:08 -0700 (PDT)

Ignoring the separate topic of how to make two devices both behind different
NATs connect with a TCP connection, what do we want the TCP document to say
about how NATs should behave?

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Oct 2004 14:05:17 -0700 (PDT)

Off the top of my head:

* preserve TCP options
* don't require TCP keepalives to keep the connection option
* don't reuse a TCP source port until at least TIME_WAIT seconds expire
* use well-known source port range if source TCP connection was also in
well-known range
* consider draft-gont-*
* consider draft-ietf-tcpm-tcpsecure
* ICMP (both directions)
* Path MTU Discovery (both directions)
* fragmented TCP packets

-d

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Cullen
> Jennings
> Sent: Monday, October 25, 2004 6:56 AM
> To: Behave
> Subject: [Ietf-behave] TCP behavior
>
>
>
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Kaushik Biswas <[email-masked]>
Date: Mon, 25 Oct 2004 17:54:29 -0700 (PDT)

in addition:
 - make NAT entry-timers to fall-back to a lower value when
RST/FIN-ACKs seen,
 - support TCP-segments handling. This is in addition to
fragmentation support which Dan has already mentioned.

 An eg, using H323 :

 Packet 1: IP-hdr----TCP-hdr----TPKT-hdr1 +
TPKT-data1 + TPKT-hdr2
 Packet 2:
IP-hdr-----TCP-hdr----TPKT-data2

Both these packet are not IP fragments, but if the TCP MSS is
lower, then the payload carried in the TCP-data will be split into 2
packets (TCP-segments). NATs should be able to handle this.

Thanks,
Kaushik

At 02:05 PM 10/25/2004 -0700, Dan Wing wrote:
Off the top of my head:

* preserve TCP options
* don't require TCP keepalives to keep the connection option
* don't reuse a TCP source port until at least TIME_WAIT seconds
expire
* use well-known source port range if source TCP connection was also
in
well-known range
* consider draft-gont-*
* consider draft-ietf-tcpm-tcpsecure
* ICMP (both directions)
* Path MTU Discovery (both directions)
* fragmented TCP packets

-d

> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On
Behalf Of Cullen