Re: [Softwires] [v4tov6transition] ISP support of Native IPv6across NAT44 CPEs -Proposed 6a44 Specification
"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 07 October 2010 16:38 UTC
Return-Path: <Fred.L.Templin@boeing.com>
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 427713A7154; Thu, 7 Oct 2010 09:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.906
X-Spam-Level:
X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4]
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 X9VG+aEx7bnO; Thu, 7 Oct 2010 09:38:30 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 5B94D3A7158; Thu, 7 Oct 2010 09:38:30 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o97GdN7e026886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Oct 2010 09:39:24 -0700 (PDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o97GdNJK012904; Thu, 7 Oct 2010 11:39:23 -0500 (CDT)
Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o97GdM8Y012855 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 7 Oct 2010 11:39:23 -0500 (CDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Thu, 7 Oct 2010 09:39:22 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Yiu L. Lee" <yiu_lee@cable.comcast.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>
Date: Thu, 07 Oct 2010 09:39:21 -0700
Thread-Topic: [v4tov6transition] [Softwires] ISP support of Native IPv6across NAT44 CPEs -Proposed 6a44 Specification
Thread-Index: ActlqdIGu1dYQTloSA6e+ZVmJnpudwAAPoSQAAPsvTMAIEne8A==
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C59B79032@XCH-NW-01V.nw.nos.boeing.com>
References: <E1829B60731D1740BB7A0626B4FAF0A65C59B78DA4@XCH-NW-01V.nw.nos.boeing.com> <C8D29306.3EDBD%yiu_lee@cable.comcast.com>
In-Reply-To: <C8D29306.3EDBD%yiu_lee@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Softwires <softwires@ietf.org>, "v4tov6transition@ietf.org" <v4tov6transition@ietf.org>
Subject: Re: [Softwires] [v4tov6transition] ISP support of Native IPv6across NAT44 CPEs -Proposed 6a44 Specification
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: Thu, 07 Oct 2010 16:38:32 -0000
Hi Yiu, > -----Original Message----- > From: v4tov6transition-bounces@ietf.org > [mailto:v4tov6transition-bounces@ietf.org] On Behalf Of Yiu L. Lee > Sent: Wednesday, October 06, 2010 5:57 PM > To: Templin, Fred L; Brian E Carpenter; Ole Troan > Cc: Softwires; v4tov6transition@ietf.org > Subject: Re: [v4tov6transition] [Softwires] ISP support of > Native IPv6across NAT44 CPEs -Proposed 6a44 Specification > > 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. I used the double tunneling example as something that could be done and not necessarily something that should be done - it is not at all a requirement of IRON, and would not be as efficient as deploying IRON alone without also deploying 6a44 or the like. But, it might be worth noting that the hard-coded 1280 MTU precludes configuring other tunnels over 6a44 tunnels. AFAICT, if the ISPs want to let their customers set up native IPv6 networks behind unmodified IPv4 NATs the two choices are to 1) do nothing, and let outside agencies deploy the IRON service, or 2) deploy the IRON service themselves. This gets back to a point that needs to be bumped up a level in visibility. Some of these proposed approaches are strictly provider-aggregated, which may be good for the ISPs but maybe not so optimal for the customers. IRON provides the customers with a provider-independent routing and addressing service that can be carried over any ISP(s) the customers happens to procure their basic connectivity services from. About complexity comparisons, based on my limited knowledge of L2TP the IRON architectural principles don't have a parallel in the L2TP model. But, when it comes to control and data plane messaging, I can say with some confidence based on the code I am writing that IRON is much simpler. Thanks - Fred fred.l.templion@boeing.com > 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 > > _______________________________________________ > v4tov6transition mailing list > v4tov6transition@ietf.org > https://www.ietf.org/mailman/listinfo/v4tov6transition >
- Re: [Softwires] ISP support of Native IPv6 across… Yiu L. Lee
- [Softwires] ISP support of Native IPv6 across NAT… Rémi Després
- Re: [Softwires] ISP support of Native IPv6 across… Brian E Carpenter
- Re: [Softwires] ISP support of Native IPv6 across… Ole Troan
- Re: [Softwires] ISP support of Native IPv6 across… Brian E Carpenter
- Re: [Softwires] ISP support of Native IPv6 across… Templin, Fred L
- Re: [Softwires] ISP support of Native IPv6 across… Yiu L. Lee
- Re: [Softwires] ISP support of Native IPv6 across… Olivier Vautrin
- Re: [Softwires] [v4tov6transition] ISP support of… Rémi Després
- Re: [Softwires] [v4tov6transition] ISP support of… Ole Troan
- Re: [Softwires] [v4tov6transition] ISP support of… Yiu L. Lee
- Re: [Softwires] [v4tov6transition] ISP support of… Rémi Després
- Re: [Softwires] ISP support of Native IPv6 across… Rémi Després
- Re: [Softwires] [v4tov6transition] ISP support of… Templin, Fred L
- Re: [Softwires] [v4tov6transition] ISP support of… Ole Troan
- Re: [Softwires] [v4tov6transition] ISP support of… Brian E Carpenter
- Re: [Softwires] [v4tov6transition] ISP support of… Brian E Carpenter
- Re: [Softwires] ISP support of Native IPv6 across… Brian E Carpenter
- Re: [Softwires] [v4tov6transition] ISP support of… Cameron Byrne
- Re: [Softwires] IPv6 VPNs configured over 1280 MT… Templin, Fred L
- Re: [Softwires] [v4tov6transition] ISP support of… Rémi Després
- Re: [Softwires] [v4tov6transition] ISP support of… Ole Troan
- Re: [Softwires] [v4tov6transition] ISP support of… Rémi Després
- Re: [Softwires] [v4tov6transition] ISP support of… Templin, Fred L
- [Softwires] IPv6 VPNs configured over 1280 MTU tu… Templin, Fred L
- Re: [Softwires] [v4tov6transition] ISP support of… Yiu L. Lee
- Re: [Softwires] [v4tov6transition] ISP support of… Templin, Fred L
- Re: [Softwires] [v4tov6transition] ISP support of… Yiu L. Lee
- Re: [Softwires] [v4tov6transition] ISP support of… Templin, Fred L
- Re: [Softwires] [v4tov6transition] ISP support of… Yiu L. Lee
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Washam Fan
- Re: [Softwires] ISP support of Native IPv6 across… Tina TSOU
- Re: [Softwires] [v4tov6transition] ISP support of… Brian E Carpenter
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Templin, Fred L
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Rémi Després
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Templin, Fred L
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Rémi Després
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Templin, Fred L
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Templin, Fred L
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Brian E Carpenter
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Templin, Fred L
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Washam Fan
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Templin, Fred L
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Washam Fan
- Re: [Softwires] [v4tov6transition] 6a44 MTU issues Rémi Després
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Templin, Fred L
- Re: [Softwires] [v4tov6transition] 6a44 MTU issues Templin, Fred L
- Re: [Softwires] [v4tov6transition] 6a44 MTU issues Rémi Després
- Re: [Softwires] [v4tov6transition] 6a44 MTU issues Templin, Fred L
- Re: [Softwires] [v4tov6transition] 6a44 MTU issues Rémi Després
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Washam Fan
- Re: [Softwires] [v4tov6transition] 6a44 MTU issues Templin, Fred L
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Templin, Fred L
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Brian E Carpenter
- Re: [Softwires] [v4tov6transition] IPv6 VPNs conf… Templin, Fred L