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

Dmitry Anipko <Dmitry.Anipko@microsoft.com> Fri, 24 February 2012 00:22 UTC

Return-Path: <Dmitry.Anipko@microsoft.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 6A4FD21F88B0 for <behave@ietfa.amsl.com>; Thu, 23 Feb 2012 16:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 h1qTy+BSxm3p for <behave@ietfa.amsl.com>; Thu, 23 Feb 2012 16:22:03 -0800 (PST)
Received: from TX2EHSOBE003.bigfish.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3366921F88A3 for <behave@ietf.org>; Thu, 23 Feb 2012 16:21:50 -0800 (PST)
Received: from mail28-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Feb 2012 00:21:49 +0000
Received: from mail28-tx2 (localhost [127.0.0.1]) by mail28-tx2-R.bigfish.com (Postfix) with ESMTP id 600AA3205D1 for <behave@ietf.org>; Fri, 24 Feb 2012 00:21:49 +0000 (UTC)
X-SpamScore: -5
X-BigFish: VS-5(zzc85fh179cMzz1202hzz8275bh8275dhz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail28-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail28-tx2 (localhost.localdomain [127.0.0.1]) by mail28-tx2 (MessageSwitch) id 1330042896405731_23320; Fri, 24 Feb 2012 00:21:36 +0000 (UTC)
Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.248]) by mail28-tx2.bigfish.com (Postfix) with ESMTP id 2FCD2440069 for <behave@ietf.org>; Fri, 24 Feb 2012 00:21:27 +0000 (UTC)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Feb 2012 00:21:26 +0000
Received: from TK5EX14MBXC265.redmond.corp.microsoft.com ([169.254.3.108]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0247.005; Thu, 23 Feb 2012 16:21:25 -0800
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: "behave@ietf.org" <behave@ietf.org>
Thread-Topic: NAT64: clarification on RST handling in V6 FIN RCV state
Thread-Index: Aczyijvg7tx51T/RTcC0uSBh3Nq7LQ==
Date: Fri, 24 Feb 2012 00:21:24 +0000
Message-ID: <03FE6A726D13284495EF1787D25F1DF915D3F7EB@TK5EX14MBXC265.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.71]
Content-Type: multipart/alternative; boundary="_000_03FE6A726D13284495EF1787D25F1DF915D3F7EBTK5EX14MBXC265r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [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: Fri, 24 Feb 2012 00:22:04 -0000

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