[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