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:55 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 E400D3A6ED7; Wed, 6 Oct 2010 17:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.247
X-Spam-Level:
X-Spam-Status: No, score=-104.247 tagged_above=-999 required=5 tests=[AWL=2.149, 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 r5AliF0fAmn3; Wed, 6 Oct 2010 17:55:58 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 5CADE3A6EB3; Wed, 6 Oct 2010 17:55:58 -0700 (PDT)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.96772974; Wed, 06 Oct 2010 20:56:43 -0400
Received: from PACDCEXCMB04.cable.comcast.com (24.40.15.86) by PACDCEXHUB02.cable.comcast.com (24.40.55.41) with Microsoft SMTP Server id 14.1.218.12; Wed, 6 Oct 2010 20:56:43 -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:56:42 +0000
User-Agent: Microsoft-Entourage/12.26.0.100708
Date: Wed, 6 Oct 2010 20:56:38 -0400
From: "Yiu L. Lee" <yiu_lee@cable.comcast.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>
Message-ID: <C8D29306.3EDBD%yiu_lee@cable.comcast.com>
Thread-Topic: [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
Thread-Index: ActlqdIGu1dYQTloSA6e+ZVmJnpudwAAPoSQAAPsvTM=
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65C59B78DA4@XCH-NW-01V.nw.nos.boeing.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: Softwires <softwires@ietf.org>, "v4tov6transition@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:56:00 -0000

Hi Fred,

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. This double tunneling tech seems scary.

Thanks,
Yiu


On 10/6/10 7:21 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:

> Hi Brian, 
> 
>> -----Original Message-----
>> From: softwires-bounces@ietf.org
>> [mailto:softwires-bounces@ietf.org] On Behalf Of Brian E Carpenter
>> Sent: Wednesday, October 06, 2010 3:10 PM
>> To: Ole Troan
>> Cc: Softwires; v4tov6transition@ietf.org
>> Subject: Re: [Softwires] ISP support of Native IPv6 across
>> NAT44 CPEs -Proposed 6a44 Specification
>> 
>> 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.
> 
> I agree that the tunnel endpoint device in the end user
> network needs to configure the 6a44 tunnel interface as a
> host interface, but if the device also configures another
> tunnel over *that* then the inner tunnel could be used as
> a router interface.
> 
> If you can bear with me for a moment (*), consider the 6a44
> tunnel as an underlying interface over which the tunnel
> endpoint device configures an IRON tunnel. Yes, that would
> make for nested encapsulations - in particular, the nesting
> would be IPv6-in-IPv6-in-UDP-in-IPv4. But, the inner tunnel
> could be used as a router interface to service a PI IPv6
> prefix. This would work even if the inner tunnel was
> configured over multiple underlying 6a44 tunnels - one
> each for each ISP the end user network connects to.
> 
> (*) Of course, the sticking point once again is the pesky
> tunnel MTU issue. 6a44 appears to be punting on MTU yet
> again and setting a static 1280 MTU. That means that there
> is not enough available MTU to configure another tunnel
> over the 6a44 tunnel without fragmentation. If 6a44 is
> already implementing a control message protocol as per
> the I-D, however, it could also add a 6a44 "Packet Too
> Big" control message and use the IRON/SEAL method for
> reporting fragmentation as a means for supporting path
> MTU discovery. If you'd like a more detailed discussion
> of this idea, let me know.
> 
> Thanks - Fred
> fred.l.templin@boeing.com
> 
>> (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
>> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires