Re: [Softwires] Call for agenda items

Rémi Després <remi.despres@free.fr> Tue, 19 October 2010 07:24 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10343A6AE8 for <softwires@core3.amsl.com>; Tue, 19 Oct 2010 00:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.414
X-Spam-Level:
X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[AWL=0.535, 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 dlXtB41hL64Y for <softwires@core3.amsl.com>; Tue, 19 Oct 2010 00:24:59 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by core3.amsl.com (Postfix) with ESMTP id CE2893A683F for <softwires@ietf.org>; Tue, 19 Oct 2010 00:24:58 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id BE2E07000087; Tue, 19 Oct 2010 09:26:28 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 7BAA37000082; Tue, 19 Oct 2010 09:26:28 +0200 (CEST)
X-SFR-UUID: 20101019072628507.7BAA37000082@msfrf2117.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <71AEEEFE-D00C-4582-B9CD-7614416BE00C@juniper.net>
Date: Tue, 19 Oct 2010 09:26:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <945CF8BD-A02A-4FFE-8279-B8A2757E5245@free.fr>
References: <71AEEEFE-D00C-4582-B9CD-7614416BE00C@juniper.net>
To: Alain Durand <adurand@juniper.net>, David Ward <dward@juniper.net>
X-Mailer: Apple Mail (2.1081)
Cc: Softwires list <softwires@ietf.org>
Subject: Re: [Softwires] Call for agenda items
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Oct 2010 07:24:59 -0000

Hi, Alain and David,

I would like to have 10 min to present tools.ietf.org/id/draft-despres-softwire-4rd-00.

In view of the support expressed by four ISPs in www.ietf.org/mail-archive/web/v6ops/current/msg05247, the subject is important.
It would normally require much more than 10 min but, unless you could get more time for Softwire, a brief introduction would be better than nothing.

Thank you.
RD




      IPv4 Residual Deployment across IPv6-Service networks (4rd)
                          A NAT-less solution
                     draft-despres-softwire-4rd-00

Abstract

   During the long transition period from IPv4-only to IPv6-only,
   networks will have not only to deploy the IPv6 service but also to
   maintain some IPv4 connectivity for a number of customers, and this
   for both outgoing and incoming connections and for both customer-
   individual and shared IPv4 addresses.  The 4rd solution (IPv4
   Residual Deployment) is designed as a lightweight solution for this.
   It applies not only to ISPs have IPv6-only routing networks, but also
   to those that, during early transition stages, have IPv4-only
   routing, with 6rd to offer the IPv6 service, those that have dual-
   stack routing networks but with private IPv4 addresses assigned to
   customers.
   In some scenarios, 4rd can dispense ISPs from supporting any NAT in
   their infrastructures.  In some others it can be used in parallel
   with NAT-based solutions such as DS-lite and/or NAT64/DNS4 which
   achieve better IPv4-address sharing ratios (but at a price of
   significantly higher operational complexity).