Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

<mohamed.boucadair@orange.com> Thu, 14 February 2013 06:51 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E40621F88B4 for <int-area@ietfa.amsl.com>; Wed, 13 Feb 2013 22:51:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.132
X-Spam-Level:
X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz+mkOVox5iI for <int-area@ietfa.amsl.com>; Wed, 13 Feb 2013 22:51:34 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9B95D21F86F2 for <int-area@ietf.org>; Wed, 13 Feb 2013 22:51:32 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 74508264216; Thu, 14 Feb 2013 07:51:31 +0100 (CET)
Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 53B4A4C024; Thu, 14 Feb 2013 07:51:31 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 14 Feb 2013 07:51:31 +0100
From: mohamed.boucadair@orange.com
To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Thu, 14 Feb 2013 07:51:29 +0100
Thread-Topic: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis
Thread-Index: Ac4KHZZ8NqCwoT7RTNm7AubnrgjggAAYbOIA
Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB564BB@PUEXCB1B.nanterre.francetelecom.fr>
References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <CAC8QAcc_r3U5GqTp=yBp4K0JOvSh2i2fWxVm=5rQHc-gqxcwCw@mail.gmail.com> <511B393A.7080709@ericsson.com> <CAC8QAceQo5-8p7aBR=AuNKZeCaensP880qAbAmS86HO6eK8b5g@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EAFB56426@PUEXCB1B.nanterre.francetelecom.fr> <CAC8QAceY0M2iv974zaj9_xBouFaN8q1wf+ecXy3zAZfG98EqnQ@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EAFB56457@PUEXCB1B.nanterre.francetelecom.fr> <CAC8QAccj=_AhgLooNd+Cv4ogJ=h5FuNFJwmN01Q+ap8YyF9uCQ@mail.gmail.com>
In-Reply-To: <CAC8QAccj=_AhgLooNd+Cv4ogJ=h5FuNFJwmN01Q+ap8YyF9uCQ@mail.gmail.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EAFB564BBPUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.14.54223
Cc: "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" <draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2013 06:51:35 -0000

Hi Behcet,

I'm aware of that context but the problem is that I don't have a good reference to cite for it. http://tools.ietf.org/id/draft-schott-fmc-requirements-02.txt would be a good reference to cite but unfortunately the port set section was removed in the last version http://tools.ietf.org/html/draft-schott-fmc-requirements-04.

Saying that, I really think having one example to cite is sufficient. No need to have an exhaustive reference list.

Thanks.

Cheers,
Med

________________________________
De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
Envoyé : mercredi 13 février 2013 20:09
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Suresh Krishnan; Brian Haberman; draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org; int-area@ietf.org
Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

Hi Med,

I think that email discussions we had on this issue in fmc list last year will provide good context in these discussions, please remember them.

See inline:

On Wed, Feb 13, 2013 at 11:16 AM, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Re-,

Please see inline.

Cheers,
Med

________________________________
De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>]
Envoyé : mercredi 13 février 2013 18:01
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Suresh Krishnan; Brian Haberman; draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org<mailto:draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org>; int-area@ietf.org<mailto:int-area@ietf.org>

Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

Hi Med,

On Wed, Feb 13, 2013 at 10:43 AM, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Hi Behcet,

I have two comments:

* Host identification issue is valid for any address sharing mechanism.

I am not sure on A+P?
[Med] both A+P and NAT-based address sharing solutions are covered by rfc6269. host identifier is just a means to distinguish hosts under the same IP address. It does not matter how address sharing is implemented.

A+P requires point-to-point link, right?
This is why the introduction mentions already the following:

   As reported in [RFC6269<https://tools.ietf.org/html/rfc6269>], several issues are encountered when an IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P [RFC6346<https://tools.ietf.org/html/rfc6346>].

* RFC6346 is provided as an example of a solution making use of port sets. You are right, other solutions (than a+p) can be considered but having one pointer to a solution example is just fair. No need to be exhaustive here.

Again, I am not sure if Section 4.6 describes what A+P says?
[Med] That section says non overlapping port sets are assigned to hosts sharing the same IP address. The text does not describe if the shared address is also configured to those hosts or if there is a NAT in the host, etc. These are implementation variants. There is no value to provide such details in that section. Adding a ref to A+P is just fair. This does not preclude other contexts.


If Section 4.6 applies to A+P, there is no need for such a text, just say Use A+P and give the reference, right?

Regards,

Behcet