Subject: [BEHAVE] remaining open issues with stateful nat64 draft

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 16 Jan 2010 14:44:54 +0100

Hi,

We have at least the following open issues:

1- Whether we fully honour RFC 5382 Req4, that the nat should send ICMP 
error back after 6 secs upon if it decides to discard an unsolicited v4 
syn. as currently defined, we siltenty drop the packet.

2- whether the nat64 should issue TCP keepalives in order to test 
whether a TCP session is active, before deleting the session entry when 
the timer expires.

3- whether we should increase the UDP session lifetime timer based on 
the lifetime of the session.

I am uncertain on how to proceed with any of  these issues.

Comments?

Regards, marcelo

---

From: Lars Eggert <[email-masked]>
Date: Mon, 18 Jan 2010 12:19:34 +0200

Hi,

me two cents:

> syn. as currently defined, we siltenty drop the packet.

yes, you should fully honor 5382. It makes no sense for different documents out of the WG that was chartered to do NAT regularization to recommend different things.

> whether a TCP session is active, before deleting the session entry when 

Sounds useful - are the details of this described currently? (I guess you'd do a keepalive test on both sides?)

> the lifetime of the session.

I'd just recommend a decently-long fixed timeout. An application that manages to keep a UDP session going for a long time will see no benefit, and an application that cannot do this won't get to the point where it'll be rewarded with a longer timeout...

Lars

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 19 Jan 2010 14:14:19 +0100

> yes, you should fully honor 5382. It makes no sense for different documents out of the WG that was chartered to do NAT regularization to recommend different things.

ok, i will change the draft to reflect this
> Sounds useful - are the details of this described currently? (I guess you'd do a keepalive test on both sides?)

this is under discussion in another thread
> I'd just recommend a decently-long fixed timeout. An application that manages to keep a UDP session going for a long time will see no benefit, and an application that cannot do this won't get to th…
right, i agree
the current draft has a default value of 5 min as defined in rfc4787, so 
i think this should do it.

Regards, marcelo