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

"Yiu L. Lee" <yiu_lee@cable.comcast.com> Thu, 07 October 2010 00:45 UTC

Return-Path: <yiu_lee@cable.comcast.com>
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 9E2F93A722F; Wed, 6 Oct 2010 17:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.145
X-Spam-Level:
X-Spam-Status: No, score=-104.145 tagged_above=-999 required=5 tests=[AWL=2.251, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100]
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 iXlzellqg5Le; Wed, 6 Oct 2010 17:45:22 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 12EFA3A7226; Wed, 6 Oct 2010 17:45:21 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.96772418; Wed, 06 Oct 2010 20:46:19 -0400
Received: from PACDCEXCMB04.cable.comcast.com (24.40.15.86) by pacdcexhub03.cable.comcast.com (24.40.55.40) with Microsoft SMTP Server id 14.1.218.12; Wed, 6 Oct 2010 20:46:19 -0400
Received: from 68.81.91.8 ([68.81.91.8]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server legacywebmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Oct 2010 00:46:18 +0000
User-Agent: Microsoft-Entourage/12.26.0.100708
Date: Wed, 6 Oct 2010 20:46:17 -0400
From: "Yiu L. Lee" <yiu_lee@cable.comcast.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>
Message-ID: <C8D29099.3EDBA%yiu_lee@cable.comcast.com>
Thread-Topic: [Softwires] ISP support of Native IPv6 across NAT44 CPEs - Proposed 6a44 Specification
Thread-Index: ActluQzmAvo6891XdUKcxiIMZVQCww==
In-Reply-To: <4CACF3D3.8060006@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
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 00:45:23 -0000

Agree because 6a44 address schema won't generate a prefix shorter than /64.
Let's put the technology aside. The ultimate question is: "Will O/S vendors
be willing to consider to implement another tunnel protocol on the host?"


On 10/6/10 6:10 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:

> On 2010-10-06 19:57, Ole Troan wrote:
>> Brian,
>> 
>>>> Draft-despres-softwire-6a44-00, coauthored with Brian and Sheng, has just
>>>> been posted (http://tools.ietf.org/html/draft-despres-softwire-6a44-00).
>>>> It describes a solution for ISPs to offer native IPv6 across IPv4-only CPEs
>>>> (NAT44 CPEs).
>>>> 
>>>> It results from convergence discussion between authors of
>>>> draft-carpenter-6man-sample-00 and draft-despres-softwire-6rdplus-00,
>>>> taking into account comments made by authors of
>>>> draft-lee-softwire-6rd-udp-01, and those made other Softwire WG
>>>> participants since IETF 78.
>>>> 
>>>> It is submitted to become, after discussion in the WG, a Softwire I-D.
>>> By the way, we do discuss in the draft why it's a useful alternative to
>>> both tunnel brokers (such as Hexago and SixXs) or Teredo. We don't
>>> explicitly discuss why we think it's also a useful alternative to an L2TP
>>> solution, but the arguments are, I think, similar to those for the tunnel
>>> brokers (apart from our "hobbyist" comment).
>> 
>> perhaps you could also add some deployment considerations with regards to
>> host tunneling versus "network" tunneling?
> 
> OK, if there is enough interest to continue this work. Of course, in the
> context of legacy CPE, there is no alternative to host tunnels.
> (Except for the idea in draft-lee-softwire-6rd-udp of a tiny
> relay plugged into the customer LAN.)
> 
>      Brian
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires