Re: [shara] Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-00)

<pierre.levis@orange-ftgroup.com> Thu, 02 April 2009 14:57 UTC

Return-Path: <pierre.levis@orange-ftgroup.com>
X-Original-To: shara@core3.amsl.com
Delivered-To: shara@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CB43A697B; Thu, 2 Apr 2009 07:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.048
X-Spam-Level:
X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
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 7tKWuZsqJdrK; Thu, 2 Apr 2009 07:57:35 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 6372B3A686A; Thu, 2 Apr 2009 07:57:34 -0700 (PDT)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 16:58:36 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 02 Apr 2009 16:58:33 +0200
Message-ID: <D109C8C97C15294495117745780657AE0B8E20F7@ftrdmel1>
In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D02F7E95D@SGSINSMBS02.ad4.ad.alcatel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [shara] Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-00)
Thread-Index: AcmgdlhcsqF9XOaRSFmUv5LfTG7d5QAAEU/wA2dPQ2AASTlpgAEaJr3w
References: <986DCE2E44129444B6435ABE8C9E424D02D5CE0A@SGSINSMBS02.ad4.ad.alcatel.com> <D109C8C97C15294495117745780657AE0B7FD6FE@ftrdmel1> <986DCE2E44129444B6435ABE8C9E424D02F7E95D@SGSINSMBS02.ad4.ad.alcatel.com>
From: pierre.levis@orange-ftgroup.com
To: David.Miles@alcatel-lucent.com.au, behave@ietf.org, shara@ietf.org
X-OriginalArrivalTime: 02 Apr 2009 14:58:36.0302 (UTC) FILETIME=[7FDD4AE0:01C9B3A3]
Subject: Re: [shara] Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-00)
X-BeenThere: shara@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Sharing of an IPv4 Address discussion list <shara.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shara>
List-Post: <mailto:shara@ietf.org>
List-Help: <mailto:shara-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2009 14:57:35 -0000

Hi David,

I'm not very convinced on the interest to modelize a PRR as a NAPT function that would not do any translation.
For me it makes the PRR appear as a kind of degenerated NAT, when one of its main value is to get rid of a CGN function.


That said, I agree there is an interest to consider solutions that integrate both PRR and CGN functions.

Pierre




-----Message d'origine-----
De : MILES DAVID [mailto:David.Miles@alcatel-lucent.com.au] 
Envoyé : samedi 28 mars 2009 01:27
À : LEVIS Pierre RD-CORE-CAE; behave@ietf.org; shara@ietf.org
Objet : RE: [shara] Follow up on Layer2-Aware NAT (draft-miles-behave-l2nat-00)

Pierre,

Thanks for the support. The presentation of draft-nishitani-cgn-01
outlined a good way forward - here the Network Model was separated from
the core NAT Function. I think a L2-Aware NAT best belongs in a core
document like this.
In this way L2-Aware NAT could make up an optional component of the core
NAT Function (in the way it describes a Virtual NAT [tables] facility).
On top of this a variety of network models could be created and
documented - these could even come from other working groups (such as
Softwires).I believe a core NAT function (regardless of whether we
describe IPv4 or IPv6) fits well in BEHAVE. 

Applying the mechanisms in L2-Aware NAT to PRR makes a lot of sense as
well - I'm wondering if port-range solutions could be described (perhaps
poorly) as similar to a NAPT mapping function (outside-ip/port to
inside-ip/port) however in the case of PRR, the pairs are the
same/common - in effect a address/port translation does not occur. What
do you think of attempting to describe the PRR function like this?

If agreeable I would like to invite the authors of PRR/A+P and CGN
drafts to work within the bounds of a new draft that describes a core
NAT function (without drawing reference to size or scale) - introducing
elements of core NAT function (CGN/LSN) virtual NAPT tables (L2-Aware
NAT), and mappings tables where translation is not applied (PRR).

Best Regards,

-David

-----Original Message-----
From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf
Of pierre.levis@orange-ftgroup.com
Sent: Thursday, March 26, 2009 6:17 AM
To: behave@ietf.org; shara@ietf.org
Subject: [shara] Follow up on Layer2-Aware NAT
(draft-miles-behave-l2nat-00)

The comment I had on the mike during behave session 2:

This kind of work is very valuable, it is worth not only for CGN but
also for Port Ranges solutions and for all IPv4 shortage solutions. 
As we presented it in the shara BoF all solutions basically:
1) Put a dedicated function in an ISP Box (CGN, PRR, whatever)
2) Use some sort of transport mechanism (tunneling, layer 2, whatever)
between customers and ISPBox, 
3) Are confronted with the same issues: how to force a route from
customers to ISPBox, how to route back from ISPBox to relevant customer,
how to identify the customer. 

This would advocate for seeing all work related to IPv4 shared addresses
host in the same place, under the same ombrella.
 

Regards

Pierre
_______________________________________________
shara mailing list
shara@ietf.org
https://www.ietf.org/mailman/listinfo/shara