IETF Logo Mail Archive

Re: [Softwires] Stateless implementation plan

Rémi Després <despres.remi@laposte.net> Thu, 09 February 2012 08:40 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659B721F861E for <softwires@ietfa.amsl.com>; Thu, 9 Feb 2012 00:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JG6xVaY5lXc for <softwires@ietfa.amsl.com>; Thu, 9 Feb 2012 00:40:30 -0800 (PST)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id E14E821F8619 for <softwires@ietf.org>; Thu, 9 Feb 2012 00:40:29 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 40F637000642; Thu, 9 Feb 2012 09:40:29 +0100 (CET)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 0C6B27000140; Thu, 9 Feb 2012 09:40:28 +0100 (CET)
X-SFR-UUID: 20120209084029509.0C6B27000140@msfrf2116.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <CB582B0A.1C4E6%yiu_lee@cable.comcast.com>
Date: Thu, 09 Feb 2012 09:40:28 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <700BA18F-16F0-4DD3-ABD9-E6BFB81B00C5@laposte.net>
References: <CB582B0A.1C4E6%yiu_lee@cable.comcast.com>
To: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
X-Mailer: Apple Mail (2.1084)
X-sfr-mailing: LEGIT
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Stateless implementation plan
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 09 Feb 2012 08:40:30 -0000

Le 2012-02-08 à 19:39, Lee, Yiu a écrit :

> Hi Remi,
> 
> I know this is possible to do, in theory. However my question is more
> toward manageability of the network. IMHO, layering one tunnel (or
> translation) protocol on another tunnel protocol is asking for trouble.

No obligation to do it, of course.
Noting that it is possible doesn't hurt though.
Personally, I find it legitimate to be careful before pretending to offer more service than before, but I don't see which trouble would result from IPv6 (with IPv4 embedded addresses) encapsulated in IPv4 (with RFC1918 addresses). 

Cheers,
RD

> 
> Cheers,
> /Yiu
> 
> On 2/8/12 2:13 AM, "Rémi Després" <remi.despres@free.fr> wrote:
> 
>> 6rd can be deployed over Net-10 networks (RFC1918) to deployIPv6.
>> Shared public IPv4 addresses can then be offered to customers via this
>> IPv6.
>> Such a use case, based on the header-mappiong variant of 4rd-U rather
>> than on a double MAP encapsulation, is described in
>> tools.ietf.org/html/draft-despres-softwire-4rd-u-03#section-5.4.
>> 
>> RD
>> 
>

v2.23.0 | Report a Bug | By Email