IETF Logo Mail Archive

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

Fred Baker <fred@cisco.com> Thu, 08 March 2012 10:48 UTC

Return-Path: <fred@cisco.com>
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 A040F21F8611 for <behave@ietfa.amsl.com>; Thu, 8 Mar 2012 02:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.939
X-Spam-Level:
X-Spam-Status: No, score=-108.939 tagged_above=-999 required=5 tests=[AWL=1.660, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 xC1DZFKfRpxK for <behave@ietfa.amsl.com>; Thu, 8 Mar 2012 02:48:13 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 71B8921F85F6 for <behave@ietf.org>; Thu, 8 Mar 2012 02:48:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=209434; q=dns/txt; s=iport; t=1331203693; x=1332413293; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=WAHqJKjjbjIFxRHJX3vcl1Sj1WFWvDdwDRuNUJxnd8M=; b=DqPuLVLInpSSaZ72R+GrEx+jfpFrRyyesP4++17Acvx+knINM/HpRtMs oEGqfK1GKYFupy3lnIBucyVoReJMyMO45eGfj4zg7qt4T6HWR8KIzHC+8 QI3OnpRWtzIz3AWx5FXuNYc5z/9QB7e02X0Sr/irq5u0ASD+SX3Nzsj+4 Q=;
X-Files: 10.71.5.180.60357.txt, 10.71.5.180.60356.txt, 10.71.5.180.60355.txt, 10.71.5.180.60354.txt, 10.71.5.180.60353.txt, 10.71.5.180.60275.txt : 40475, 42751, 59188, 25226, 22418, 8835
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmsFADiOWE+rRDoJ/2dsb2JhbABCsieBGIF0gQeCCgEBAQMBEgEHAV4FCwtGVwYxBIdhBKAAAZcviiiFY2MEiFCGBYZshWSKM4JygU0
X-IronPort-AV: E=Sophos; i="4.73,551,1325462400"; d="txt'?scan'208"; a="35130613"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 08 Mar 2012 10:47:58 +0000
Received: from Freds-Computer.local (tky-vpn-client-230-92.cisco.com [10.70.230.92]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q28Alu6L021330; Thu, 8 Mar 2012 10:47:56 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 08 Mar 2012 19:47:57 +0900
X-PGP-Universal: processed; by Freds-Computer.local on Thu, 08 Mar 2012 19:47:57 +0900
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <4F585585.9000706@it.uc3m.es>
Date: Thu, 08 Mar 2012 19:47:44 +0900
Message-Id: <A89221DA-7F68-4EB2-AA7E-17DA3732937C@cisco.com>
References: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com> <4F585585.9000706@it.uc3m.es>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
X-Mailer: Apple Mail (2.1084)
Content-Type: multipart/mixed; boundary="Apple-Mail-105-709146384"
X-Mailman-Approved-At: Thu, 08 Mar 2012 09:57:25 -0800
Cc: Murari Sridharan <muraris@microsoft.com>, "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 10:48:25 -0000

On Mar 8, 2012, at 3:45 PM, marcelo bagnulo braun wrote:

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

I see them in traces. Yes, they happen. It's not what RFC 793 says, but it is often reality.

Last week, for example, I was trying to show a colleague what a long TCP trace looked like. I opened tcpdump and uploaded a picture to picasa. While that was happening, who knows what else my system was doing. In the tcpdump, I found 127 separate TCP sessions. Take a look at the trailing packets in the attached.

I didn't find a FIN (F without Ack) in any of the examples. I can send you the trace if you're interested.

v2.23.0 | Report a Bug | By Email