Re: [v4tov6transition] [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification

Rémi Després <remi.despres@free.fr> Thu, 07 October 2010 14:55 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1AA3A7122; Thu, 7 Oct 2010 07:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.523
X-Spam-Level:
X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_20=-0.74, 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 D9m7RrrB-fsC; Thu, 7 Oct 2010 07:55:38 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id 8A2B23A710C; Thu, 7 Oct 2010 07:55:38 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id 631767000091; Thu, 7 Oct 2010 16:56:40 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id C39657000081; Thu, 7 Oct 2010 16:56:37 +0200 (CEST)
X-SFR-UUID: 20101007145639801.C39657000081@msfrf2214.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <8F8FE644-4E46-4579-8D77-9C5613F6419E@employees.org>
Date: Thu, 7 Oct 2010 16:56:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BEE26F5-AB86-407C-98B2-FACADF2BBC95@free.fr>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com> <FC864BDE-D5C7-4EEF-AE66-18AF523CDB67@free.fr> <8F8FE644-4E46-4579-8D77-9C5613F6419E@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.1081)
Cc: Softwires <softwires@ietf.org>, v4tov6transition@ietf.org
Subject: Re: [v4tov6transition] [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2010 14:55:40 -0000

Le 7 oct. 2010 à 15:45, Ole Troan a écrit :

>>> This is an interesting idea, but I will argue this is as complex as L2TP
>>> softwire. When Brian, Remi and I discussed, we would like to have a simple
>>> and cost effective technology that could be deployed by SP w/o upgrading the
>>> CPE.
>> 
>> Indeed.
>> We need some reliable and easily deployable solutions for IPv6 use to become widespread, including in hosts behind legacy CPEs.
> 
> why?
> 
> my personal experience with host tunneling hasn't been great (ISATAP, Teredo, 6to4, configured, L2TP).


That is the whole point of proposing a really SIMPLE solution to solve a real problem.
 
> and do ISPs really have an interest in supporting individual hosts? and be exposed to all of their peculiarities?

ISPs that aren't concerned with what their customer would like to have will eventually face competition.
A key point is that supporting 6a44 is very inexpensive compared to other supports they have to envisage.

Yet, as Yiu says, this still depends on which hosts will support 6a44.
My personal hope is that we will soon see trials, including with mobile phones.  


> it appears to me that we are filling in every possible square in the solution matrix.

If you believe that IPv6 deployment is rapid enough, your lack of interest is understandable, but some have a different view. 

> just because it is possible doesn't mean that it is useful or deployable...

I never believed that!!!

Yet a simple, reliable, and scalable solution is sometimes a good way to cut the gordian knot.
6rd was an example, and I personally believe that 6a44 has a great potential too. 


Cheers,
RD


> 
> cheers,
> Ole