Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state

It is very dependent on higher layer behavior, but we do see cases where the close isn't graceful and we see a RST in response to a FIN. 

Thanks

________________________________________
From: marcelo bagnulo braun [marcelo@it.uc3m.es]
Sent: Wednesday, March 07, 2012 10:45 PM
To: Murari Sridharan
Cc: Dmitry Anipko; behave@ietf.org
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state

Hi Murari,

I see what you mean now (and my previous answer was wrong, so please
disregard it)

Yes it makes sense.

Do you have any hint that this will be a common case i.e. receiving a
RST as reply to a FIN?

If it is not expected to be common, i guess the normal thing will be to
receive a FIN on the other direction right away, so it may not worth the
trouble.

Regards, marcelo

El 08/03/12 07:34, Murari Sridharan escribió:
> Marcelo,
> There is discussion about how to handle RST in ESTAB state by bouncing
> off of TRANS essentially. Why cant the same thing apply to one of the
> FIN RCV state? Meaning if there is a RST, again all the caveats below
> apply, but bounce of TRANS see if the RST is accepted and further data
> flows and either move to CLOSED or come back to the FIN RCV states?
> Thanks
> Sent from my Windows 8 PC <http://windows.microsoft.com/consumer-preview>
> *From:* marcelo bagnulo braun
> *Sent:* Wednesday, March 07, 2012 10:27:13 PM
> *To:* Dmitry Anipko
> *CC:* behave@ietf.org, Murari Sridharan
> *Subject:* Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN
> RCV state
> Hi Dimitry,
>
> We had a long discussion about how to handle RST packets and the
> possibility of using an RST packet in a mailicious way was a concern,
> also considering that the nat64 is unable to determine how the host
> would handle the RST packet.
> Because of this, we decided to go the conservative way and don't change
> the nat64 state upon the reception of a RST packet.
>
> We also had a long discussion that there may be some more fine grained
> ways to deal with this depending whether it comes from the internal side
> or the external side.
>
> The particular case you discuss i don't think we explicilty discussed
> it, but i guess it falls in the aforementioned case of higher
> granularity and my take is the same as above. It could be a reaosnable
> optimization, but it woudl increase the complexity of the implementation.
>
> I hope this makes sense.
>
> Regards, marcelo
>
>
>
> El 08/03/12 01:06, Dmitry Anipko escribió:
> >
> > I’ve not seen any responses, comments would be appreciated.
> >
> > *From:*Dmitry Anipko
> > *Sent:* Thursday, February 23, 2012 4:21 PM
> > *To:* behave@ietf.org
> > *Subject:* NAT64: clarification on RST handling in V6 FIN RCV state
> >
> > Hello,
> >
> > RFC 6146, section 3.5.2.2, says that in V6 FIN RCV state **any**
> > packet other than V4 FIN must set the session lifetime to no less than
> > TCP_EST=2hours.
> >
> > If the V4 target sent RST in response to the translated V6 FIN, what
> > is the reason to keep the NAT mapping alive for TCP_EST instead of
> > TCP_TRANS?
> >
> > Should the language “if a V4 FIN packet is received,… lifetime is set
> > to TCP_TRANS” be changed to “if a V4 FIN or V4 RST packet is
> > received,… lifetime is set to TCP_TRANS”?
> >
> > -Dmitry
> >
> >
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
>
>