Re: [BEHAVE] General Comments on xlate-stateful-07

[Reinaldo Penno <[e-mail]>]

That is fine. It seems we agree with the first part of the the
interpretation, so let's take a step further.

Let's suppose you configure the idle timeout to be 30 minutes, send N
keep-alive TCP packets, receive no response, and proceed to delete the NAT
mapping. Is this behavior compliant of REQ-5? And how about NAT64?

Thanks,

Reinaldo


On 1/18/10 2:32 AM, "Lars Eggert" <[e-mail]> wrote:

> Hi,
> 
> On 2010-1-18, at 1:11, Reinaldo Penno wrote:
>> What I mean is that the sentence starts of with "In such cases...".  These
>> 'cases' are those when the NAT cannot determine whether the endpoints of a
>> TCP connection are active, as written.
> 
> right. I believe the thinking was that if you can detect whether the session
> is alive, you wouldn't time it out if it was, and you would of course time it
> out if it wasn't.
> 
> If you cannot determine this, then the default applies (and can't be shorter
> than 2 hours.)
> 
> Lars
> 
>> Therefore this first paragraph only applies to this condition. If you can
>> actually determine if the NAT endpoints are alive, you do not need to follow
>> this paragraph. 
>> 
>> My opinion is that we should just follow REQ-5 as stated. This is would take
>> care of Bryan's proposal as well.
>> 
>> 
>> 
>> 
>> On 1/17/10 4:07 AM, "marcelo bagnulo braun" <[e-mail]> wrote:
>> 
>>> Reinaldo Penno escribió:
>>>> It clearly says in a)  that the idle timeout MAY be configurable. How
>>>> will my proposed text break 5382?
>>>> 
>>> 
>>> THere are two conditions:
>>> MUST be more than 2 hours and 4 min
>>> MAY be configurable.
>>> 
>>> So, my reading of the conditions is an AND of the two conditions, not an
>>> OR.
>>> Maybe someone else should comment whether they think it is an AND or an
>>> OR....?
>>> 
>>> If it is an AND, then you can configire the timer, but needs to be
>>> higher than 2 hours and 4 min, in any case, as it is currently stated in
>>> the draft
>>> 
>>> It is is an OR, it is as you say, but at this point i don't interpret
>>> the text as a OR
>>>> It also says that only in case the NAT cannot determine if endpoints
>>>> are alive.
>>>> 
>>>> 
>>> 
>>> right, we are having a disucssion whether the nat64 should send
>>> keepalives to do this, do you think it should or not?
>>> 
>>> 
>>> 
>>>> Why we just then just copy REQ5 verbatim?
>>>> 
>>>> 
>>> on the light of this discussion, it seems that the current wording is
>>> unclear, since you and me have different readings of it
>>> 
>>> Regards, marcelo
>>> 
>>> 
>>>> On Jan 16, 2010, at 14:34, "marcelo bagnulo braun"
>>>> <[e-mail]> wrote:
>>>> 
>>>> 
>>>>> Reinaldo Penno escribió:
>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> Comment inline...
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>> Moreover, the ability to
>>>>>>>> configure the idle-timeout is also missing.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> right,
>>>>>>> 
>>>>>>> i have added the follwoing text in all the occureences of the the
>>>>>>> setting of the TCP session entry lifetite
>>>>>>> 
>>>>>>>                   The lifetime of the TCP session table entry is
>>>>>>> set
>>>>>>> to at least to the maximum session lifetime. The value for the
>>>>>>> maximum
>>>>>>>                   session lifetime MAY be configurable but it
>>>>>>> MUST not
>>>>>>> be less than TCP_EST (the
>>>>>>>                   established connection idle timeout as defined in
>>>>>>> <xref target="RFC5382"></xref>). The default value for the maximum
>>>>>>> session lifetime
>>>>>>>                   SHOULD be set to TCP_EST.
>>>>>>> 
>>>>>>> 
>>>>>> The whole purpose to have it configurable was to be able to
>>>>>> configure it to
>>>>>> be _less_ than TCP_EST.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> no, that would break REQ5 of RFC5382 that reads:
>>>>> 
>>>>>  REQ-5:  If a NAT cannot determine whether the endpoints of a TCP
>>>>>     connection are active, it MAY abandon the session if it has been
>>>>>     idle for some time.  In such cases, the value of the "established
>>>>>     connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
>>>>>     The value of the "transitory connection idle-timeout" MUST NOT be
>>>>>     less than 4 minutes.
>>>>>     a) The value of the NAT idle-timeouts MAY be configurable.
>>>>> 
>>>>> 
>>>>> 
>>>>>> The text above does not allow it to be set to less than TCP_EST. I
>>>>>> suggest
>>>>>> 
>>>>>> "The lifetime of the TCP session table entry is set
>>>>>> to at least to the maximum session lifetime. The value for the
>>>>>> maximum
>>>>>> session lifetime MAY be configurable  The default value for the
>>>>>> maximum
>>>>>> session lifetime SHOULD be set to TCP_EST."
>>>>>> 
>>>>>> Tuning TCP idle timeout is widely supported and used.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> right, but the minimum value MOST NOT be less than 2 hours and 4 min
>>>>> 
>>>>>>>> REQ-5: In the NAT64 spec the considerations on NAT throughput
>>>>>>>> performance
>>>>>>>> due to holding session state for TCP RST and TIME_WAIT
>>>>>>>> assassinations due to
>>>>>>>> holding session state are not discussed.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> REQ5 leaves these aspects open and so the nat64 specification. Do
>>>>>>> you
>>>>>>> have any particualr text that you would like to cinlcude in the
>>>>>>> nat64
>>>>>>> spec w.r.t. this?
>>>>>>> 
>>>>>>> 
>>>>>> The exact same text (or a reference to it) found in RFC5382.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> could you point out what exact same text you are referring to?
>>>>> 
>>>>> Regards, marcelo
>>>>> 
>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Reinaldo
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>> 
>> 
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>