Re: [nat66] Residential use case

Rémi Després <remi.despres@free.fr> Mon, 25 October 2010 17:32 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: nat66@core3.amsl.com
Delivered-To: nat66@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F4F3A6B0E for <nat66@core3.amsl.com>; Mon, 25 Oct 2010 10:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.503
X-Spam-Level:
X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 2PoEObaZI+s6 for <nat66@core3.amsl.com>; Mon, 25 Oct 2010 10:32:49 -0700 (PDT)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by core3.amsl.com (Postfix) with ESMTP id 30CCE3A6BE4 for <nat66@ietf.org>; Mon, 25 Oct 2010 10:32:18 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id B1DF3700008E; Mon, 25 Oct 2010 19:34:01 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id 96CC97000094; Mon, 25 Oct 2010 19:34:00 +0200 (CEST)
X-SFR-UUID: 20101025173400617.96CC97000094@msfrf2409.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <795ED9F8-227E-41A3-9B96-39D7A79A8FF6@cisco.com>
Date: Mon, 25 Oct 2010 19:33:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <54D2DE02-3CA2-4B7A-A00B-0C25DC532E63@free.fr>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB306BCC4418F@Skyhawk> <64699DF7-4F81-4AE6-80D6-1505E5EE7F2F@free.fr> <20101025155939.GU32268@Space.Net> <3C7FE7D7-83CE-4751-910C-C8CD0FC452D1@free.fr> <9FCA5FEC-FB26-41EB-AD67-E4D4CC7DC9B4@gmail.com> <795ED9F8-227E-41A3-9B96-39D7A79A8FF6@cisco.com>
To: Fred Baker <fred@cisco.com>
X-Mailer: Apple Mail (2.1081)
Cc: Margaret Wasserman <margaretw42@gmail.com>, Keith Moore <moore@network-heretics.com>, "nat66@ietf.org HappyFunBall" <nat66@ietf.org>
Subject: Re: [nat66] Residential use case
X-BeenThere: nat66@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "List for discussion of IPv6-to-IPv6 NAT." <nat66.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nat66>
List-Post: <mailto:nat66@ietf.org>
List-Help: <mailto:nat66-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Oct 2010 17:32:51 -0000

Le 25 oct. 2010 à 19:12, Fred Baker a écrit :

> 
> On Oct 25, 2010, at 10:05 AM, Margaret Wasserman wrote:
> 
>> On Oct 25, 2010, at 12:09 PM, Rémi Després wrote:
>>> It seems you accept that it may do some "harm" in the residential case (which is the case I discuss: unmanaged CPEs).
>> 
>> Then we are in complete agreement.  NAT66 isn't needed for most home users
>> -- a stateful firewall would serve the same purpose.

My point is that a FW isn't needed and is even harmful in UNMANAGED CPEs, and is even harmful because without CPE management it would prevent any incoming connectivity and simple IPv6 peer-to-peer.


> You may be interested to review 
> http://tools.ietf.org/html/draft-troan-multihoming-without-nat66
>  "IPv6 Multihoming without Network Address Translation", Ole Troan, David
>  Miles, Satoru Matsushima, Tadahisa Okimoto, Dan Wing, 26-Jul-10
> 
> The question of multihoming with or without NAT66 (specifically referring to this draft) was brought up by a large residential access provider, who given current solutions sees NAT66 as the only solution to its *residential* problems. Basically, the point of the draft is to describe their scenario and state that they need solutions to three residential problems or they will consider themselves as having no alternative to NAT66.

I can only repeat that I tried to find a solution without NAT66, and that I believe it does exists.
It is described in tools.ietf.org/html/draft-despres-softwire-sam-01, in particular sec 3.3.

Claiming that there is no alternative to NAT66 without looking at it and commenting is IMHO unfortunate.
One reason for it to be unfortunate is that restoring e2e address preservation is what can make SHIM6 and SCTP to work.

Regards,
RD