[BEHAVE] Comments on draft-bagnulo-behave-nat64-00: NAT
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 24 July 2008 15:21 UTC
Return-Path: <behave-bounces@ietf.org>
X-Original-To: behave-archive@optimus.ietf.org
Delivered-To: ietfarch-behave-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F92F3A6A4D; Thu, 24 Jul 2008 08:21:22 -0700 (PDT)
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D564A3A6A4D for <behave@core3.amsl.com>; Thu, 24 Jul 2008 08:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.208
X-Spam-Level:
X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Joow7nFYduOE for <behave@core3.amsl.com>; Thu, 24 Jul 2008 08:21:20 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 317A13A6901 for <behave@ietf.org>; Thu, 24 Jul 2008 08:21:20 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0C9362111E; Thu, 24 Jul 2008 17:22:04 +0200 (CEST)
X-AuditID: c1b4fb3e-ab192bb000004ec0-df-48889e1b9fc4
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DF7F72011F; Thu, 24 Jul 2008 17:22:03 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 17:22:03 +0200
Received: from [147.214.183.47] ([147.214.183.47]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 17:22:03 +0200
Message-ID: <48889E1B.5000306@ericsson.com>
Date: Thu, 24 Jul 2008 17:22:03 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Behave WG <behave@ietf.org>, marcelo bagnulo braun <marcelo@it.uc3m.es>, Philip Matthews <philip_matthews@magma.ca>, Iljitsch van Beijnum <iljitsch@muada.com>
X-Enigmail-Version: 0.95.6
X-OriginalArrivalTime: 24 Jul 2008 15:22:03.0373 (UTC) FILETIME=[067249D0:01C8EDA1]
X-Brightmail-Tracker: AAAAAA==
Subject: [BEHAVE] Comments on draft-bagnulo-behave-nat64-00: NAT
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: behave-bounces@ietf.org
Errors-To: behave-bounces@ietf.org
Authors, (As individual) I read your document and I kind of reacted to that you call the translation process being like SIIT. To me it seems not to fulfill the one to one mapping that SIIT does and not touching ports. So I think you are much more in the region of doing things similar to a IPv4-IPv4 NAT with the IPv6 being the private side. You will have to deal with all the gory details of transport protocol translations and their affect on ICMP. I am at least one that think when specifying these devices also should include support for our newer transport protocols. Especially as there is relatively little that blocks them in the IPv6 world compared to IPv4. And if initiating from IPv6 then you can expect most servers to have public IPv4 address that may actually be reachable over DCCP or SCTP. So not specifying how to handle these protocols will be simply one more roadblock against there usage and a better future. I get the impression that your device will at least be performing address independent mapping allowing current STUN and ICE based or similar NAT traversal to work. However, when it comes to filtering, is really the NAT64 the place to perform any filtering. Isn't it much simpler and requiring less state to be non-filtering when it comes to mapping and let the receiving host deal with any unwanted traffic? Then there is the mapping lifetime question. You specify the maximum lifetime to 5 minutes for UDP. What timer length where you considering for TCP? Have you made any considerations on what traffic directions that will keep the timer alive? Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Färögatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave
- [BEHAVE] Comments on draft-bagnulo-behave-nat64-0… Magnus Westerlund
- Re: [BEHAVE] Comments on draft-bagnulo-behave-nat… marcelo bagnulo braun
- Re: [BEHAVE] Comments on draft-bagnulo-behave-nat… Magnus Westerlund
- Re: [BEHAVE] Comments on draft-bagnulo-behave-nat… Philip Matthews