IETF Logo Mail Archive

Re: [BEHAVE] proprietary implementation v.s standardised protocols//re: draft-xu-behave-nat-state-sync-00

<mohamed.boucadair@orange-ftgroup.com> Thu, 26 November 2009 13:38 UTC

Return-Path: <mohamed.boucadair@orange-ftgroup.com>
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 691D73A68FD for <behave@core3.amsl.com>; Thu, 26 Nov 2009 05:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.876
X-Spam-Level:
X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 wNQjFdLkD2CN for <behave@core3.amsl.com>; Thu, 26 Nov 2009 05:38:03 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 4EEAE3A68B8 for <behave@ietf.org>; Thu, 26 Nov 2009 05:38:03 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 42EAA3B4571; Thu, 26 Nov 2009 14:37:57 +0100 (CET)
Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 0E5B1384057; Thu, 26 Nov 2009 14:37:57 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 26 Nov 2009 14:37:56 +0100
From: mohamed.boucadair@orange-ftgroup.com
To: Simon Perreault <simon.perreault@viagenie.ca>, "behave@ietf.org" <behave@ietf.org>
Date: Thu, 26 Nov 2009 14:37:55 +0100
Thread-Topic: [BEHAVE] proprietary implementation v.s standardised protocols//re: draft-xu-behave-nat-state-sync-00
Thread-Index: Acpul1og7lIed6S8RKmPxlu7pg39bwABX00g
Message-ID: <8347_1259242677_4B0E84B5_8347_20736_1_94C682931C08B048B7A8645303FDC9F307919CD2FE@PUEXCB1B.nanterre.francetelecom.fr>
References: <004301ca6e3b$304eb1f0$d40c6f0a@china.huawei.com> <4B0E315A.1070104@it.uc3m.es> <4B0E33D6.8090902@joelhalpern.com> <4B0E37FF.4050103@it.uc3m.es> <4B0E7A19.4000506@viagenie.ca>
In-Reply-To: <4B0E7A19.4000506@viagenie.ca>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.11.26.132420
Subject: Re: [BEHAVE] proprietary implementation v.s standardised protocols//re: draft-xu-behave-nat-state-sync-00
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/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, 26 Nov 2009 13:38:04 -0000

Dear Simon, all,

Please see inline.

Cheers
Med, 

-----Message d'origine-----
De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Simon Perreault
Envoyé : jeudi 26 novembre 2009 13:53
À : behave@ietf.org
Objet : Re: [BEHAVE] proprietary implementation v.s standardised protocols//re: draft-xu-behave-nat-state-sync-00

marcelo bagnulo braun wrote, on 2009-11-26 03:10:
> I think we are basically exploring whether it is worth (and if it is
> possible) to standardize a  protocol to synchronize nat state.
> 
> The reason for doing that is that as you mention, there is a vlaue in
> allowing multiple boxes from multiple vendors to be used in synch i.e.
> interoperability.
> 
> The reasons for not doing so are less obvious i agree.

My concern is that with the immense variation in behaviour among current NAT44
implementations, there is a very low chance of success for a standardized NAT44
state synchronization protocol.

Med: Should be moderated, because we are currently in phase of studying how to introduce
DS-lite CGN (which is NAT44+IPv4-in-IPv6 encapsulation) for instance.

By only focusing on NAT64, we would increase our chances.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

v2.23.0 | Report a Bug | By Email