Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
marcelo bagnulo braun <marcelo@it.uc3m.es> Thu, 08 March 2012 06:45 UTC
Return-Path: <marcelo@it.uc3m.es>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D81721E8017 for <behave@ietfa.amsl.com>; Wed, 7 Mar 2012 22:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SG3bt+-ditT for <behave@ietfa.amsl.com>; Wed, 7 Mar 2012 22:45:27 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8F47F21F862F for <behave@ietf.org>; Wed, 7 Mar 2012 22:45:27 -0800 (PST)
X-uc3m-safe: yes
Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 14B75C1BBB8; Thu, 8 Mar 2012 07:45:26 +0100 (CET)
Message-ID: <4F585585.9000706@it.uc3m.es>
Date: Thu, 08 Mar 2012 07:45:25 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Murari Sridharan <muraris@microsoft.com>
References: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com>
In-Reply-To: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18760.003
Cc: "behave@ietf.org" <behave@ietf.org>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 06:45:29 -0000
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 > >
- [BEHAVE] NAT64: clarification on RST handling in … Dmitry Anipko
- Re: [BEHAVE] NAT64: clarification on RST handling… Dmitry Anipko
- Re: [BEHAVE] NAT64: clarification on RST handling… marcelo bagnulo braun
- Re: [BEHAVE] NAT64: clarification on RST handling… marcelo bagnulo braun
- Re: [BEHAVE] NAT64: clarification on RST handling… Murari Sridharan
- Re: [BEHAVE] NAT64: clarification on RST handling… Murari Sridharan
- Re: [BEHAVE] NAT64: clarification on RST handling… Fred Baker
- Re: [BEHAVE] NAT64: clarification on RST handling… Wesley Eddy
- Re: [BEHAVE] NAT64: clarification on RST handling… Fred Baker
- Re: [BEHAVE] NAT64: clarification on RST handling… Wesley Eddy
- Re: [BEHAVE] NAT64: clarification on RST handling… Fred Baker