Re: [v6ops] Reasons not to endorse NAT66/6to4 (refdraft-kuarsingh-v6ops-provider-managed-tunnel-00)
"Armstrong, Bill R" <Bill.Armstrong@chartercom.com> Thu, 21 October 2010 17:19 UTC
Return-Path: <Bill.Armstrong@chartercom.com>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674163A69AF for <v6ops@core3.amsl.com>; Thu, 21 Oct 2010 10:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.437
X-Spam-Level:
X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_93=0.6, 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 28aljnsjznCB for <v6ops@core3.amsl.com>; Thu, 21 Oct 2010 10:19:19 -0700 (PDT)
Received: from mail.chartercom.com (mail.chartercom.com [24.217.29.16]) by core3.amsl.com (Postfix) with ESMTP id 23E153A6A7B for <v6ops@ietf.org>; Thu, 21 Oct 2010 10:19:04 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,218,1286168400"; d="scan'208";a="123330480"
Received: from unknown (HELO KSTLMEXHTP02.CORP.CHARTERCOM.COM) ([192.168.31.32]) by mail.chartercom.com with ESMTP; 21 Oct 2010 12:20:39 -0500
Received: from KSTLMEXCP02MBX.CORP.CHARTERCOM.COM ([192.168.31.13]) by KSTLMEXHTP02.CORP.CHARTERCOM.COM ([192.168.31.32]) with mapi; Thu, 21 Oct 2010 12:20:39 -0500
From: "Armstrong, Bill R" <Bill.Armstrong@chartercom.com>
To: Rémi Després <remi.despres@free.fr>
Date: Thu, 21 Oct 2010 12:20:36 -0500
Thread-Topic: [v6ops] Reasons not to endorse NAT66/6to4 (refdraft-kuarsingh-v6ops-provider-managed-tunnel-00)
Thread-Index: ActxPAMKH9ILHYfXR1WbpeyD6f8aUQAA4jHg
Message-ID: <E71300B9B9041340B238540990BF04530915AADB66@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM>
References: <187F9308-79C5-4A5D-95F0-0D5A23EFBB18@free.fr><4CC01B0C.5020406@inex.ie> <FE1F03BC-EB55-4117-9EF6-A73B38AFD5B4@free.fr> <1EA76BAD7F050648910C041BDDED8CD5013FDBB5@PRDCG4EXVW01-5.OSS.PRD> <E71300B9B9041340B238540990BF04530915AAD92B@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> <C4E55787-A0DE-4435-9663-3591D6F5B978@free.fr>
In-Reply-To: <C4E55787-A0DE-4435-9663-3591D6F5B978@free.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Cc: Scott Beuker <Scott.Beuker@sjrb.ca>, v6ops <v6ops@ietf.org>
Subject: Re: [v6ops] Reasons not to endorse NAT66/6to4 (refdraft-kuarsingh-v6ops-provider-managed-tunnel-00)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2010 17:19:21 -0000
So we all agree that software upgrades are the key. I'm not NOT going to support\deploy 6rd 6a44 or DS-lite because of PMT rather due to the fact that they don't exist yet, its new stuff, once software has been written and has been folded into the dev cycles of all the major hardware\software vendors then we have yet another tool that can be used to work toward ubiquitous IPv6. So while we wait, 6to4 is there NOW and what PMT adds from a functionality perspective(I think) outweighs the potential breakage concerns. -Bill -----Original Message----- From: Rémi Després [mailto:remi.despres@free.fr] Sent: Thursday, October 21, 2010 11:21 AM To: Armstrong, Bill R Cc: Scott Beuker; v6ops Subject: Re: [v6ops] Reasons not to endorse NAT66/6to4 (refdraft-kuarsingh-v6ops-provider-managed-tunnel-00) Le 21 oct. 2010 à 17:40, Armstrong, Bill R a écrit : > This is it. > > I keep hearing "just offer Native" or "deploy -[insert unreleased\un-deployed transition technology here]-" as the way to side step this proposal\problem. But I think the fundamental fact being *consistently* overlooked by the opponents to the draft is that the hands of a good deal of the operators are tied by the currently deployed(+100K's) unmanaged(not the ISPs to touch) CPE. > > If the fix offered up to "just enable Native" is "simply" replace ALL the CPE that are IPv6 incapable and\or offer firmware patches for the remaining gear then we may need to have larger discussion on economic realities. Stuff costs money, new stuff doubly so. It is NOT "simply replace ALL the CPE that are IPv6 incapable". Brian Carpenter, Sheng Jiang, and myself, propose a simple solution for native IPv6 across NAT44 CPEs i(draft-despres-softwire-6a44-00). Its limitation (strong at this point, but which may evolve as the specification gets well understood) is that it depends on an update in host software. Host software upgrades appear to be unavoidable to achieve simple, efficient, and reliable, native IPv6 across legacy CPEs. > We need to stop looking at this as an OR to SOLVE the IPv6 problem but rather view it as an AND (as seen in bANDaid) which can help foster the adoption of IPv6. We all agree, I believe, that one size doesn't fit all. The specific danger of NAT66/6to4 is that, being easy to implement and to operate, there is a temptation to deploy it. But, if deployed, it breaks things that worked before. In particular it breaks the possibility to advertise one's own 6to4 address and to be reachable at this address by IPv6 hosts that have access to a 6to4 relay. (Besides, but this is less important, the amount of user experience that could be improved by a NAT66/6to4 deployment is unclear.) Regards, RD > > > > -Bill > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Scott Beuker > Sent: Thursday, October 21, 2010 9:24 AM > To: Rémi Després; v6ops > Subject: Re: [v6ops] Reasons not to endorse NAT66/6to4 (refdraft-kuarsingh-v6ops-provider-managed-tunnel-00) > > Remi, > >> That is the point of adding clean solutions that are still missing. >> (6a44, which Brian Carpenter, Sheng Jiang, and myself, are proposing is >> precisely that. It provides a solution for hosts behind legacy CPEs, at >> a cost of simple code to be added in host-OS's, and a simple add-on in >> one or a few ISP border devices.) > > Code to be added to host operating systems? So in other words, a totally unrealistic and still-born idea. You're at least 5 years too late my friend. > > The time for idealism has come and gone. Drastic changes to the IPv6 transition landscape are no longer possible in a world where the customer purchases their own CPE devices and expects a decent few years use from them. > > Here are the current realities: > > 1) 6to4 is out there > 2) 6to4 provides a safety net to IPv6-only content for an IPv4-only user > 3) 6to4 doesn't impede native IPv6 deployment, nor is it a substitute for it > > Deal with that and move forward; or at least, please stay out of the way of those of us who are trying to. > > Promotion of your own draft is not a reason to try to impede someone else's. > > > >> 6rd concerns customer sites where CPEs can be updated, yes, but doesn't >> need PE modifications (RFC 5569 and 5969)) >> 6a44 concerns hosts behind legacy CPEs, provided they can be upgraded, >> but doesn't need PE modification either. > > So in other words, both are totally irrelevant to this discussion. Neither addresses the use case that 6to4-PMT does. Please read the draft to better understand this. > > > >> Not necessarily if taken with the appropriate tools (remember that it >> took Free.fr only 5 weeks from "no intention to support IPv6" to "It's >> deployed, our customers can turn it on"). > > Free.fr has control of the customer CPE. 6to4-PMT comes to relevance in a totally different situation. > > > >>> I am forced to admit that at this stage, we need it. >> >> I hope you will understand you are not forced at all. > > Though it's always nice to have people ready and willing to tell other network operators, in totally different markets, cultures, and technical environments, what they must and must not do... at some point you have to step back and realize that your experiences are not necessarily universally applicable. > > Thanks, > Scott > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > E-MAIL CONFIDENTIALITY NOTICE: > > > > > > > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. > > > > > > > > E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
- [v6ops] Reasons not to endorse NAT66/6to4 (ref dr… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Nick Hilliard
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Nick Hilliard
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Lee, Yiu
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Lee, Yiu
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Lee, Yiu
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Scott Beuker
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Jean-Francois.TremblayING
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Armstrong, Bill R
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Philip Homburg
- Re: [v6ops] Reasons not to endorse NAT66/6to4 james woodyatt
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Fernando Gont
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Cameron Byrne
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Armstrong, Bill R
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Fernando Gont
- Re: [v6ops] Reasons not to endorse NAT66/6to4 james woodyatt
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Templin, Fred L
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Erik Kline
- Re: [v6ops] Reasons not to endorse NAT66/6to4 (re… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Scott Beuker
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Brian E Carpenter
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Scott Beuker
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Gert Doering
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Victor Kuarsingh
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Gert Doering
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Victor Kuarsingh
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Randy Bush
- Re: [v6ops] Reasons not to endorse NAT66/6to4 james woodyatt
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Victor Kuarsingh
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Victor Kuarsingh
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Gunter Van de Velde (gvandeve)
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Marc Blanchet
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Jean-Francois.TremblayING
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Marc Blanchet
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Erik Kline
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Cameron Byrne
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Jean-Francois.TremblayING
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Marc Blanchet
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Tony Hain
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Rémi Després
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Lee, Yiu
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Marc Blanchet
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Marc Blanchet
- Re: [v6ops] Reasons not to endorse NAT66/6to4 Scott.Beuker
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Dan Wing
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… james woodyatt
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Gert Doering
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Dan Wing
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… james woodyatt
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Dan Wing
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Brian E Carpenter
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… james woodyatt
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Rémi Després
- [v6ops] Summary Observations: Reasons not to endo… Joel Jaeggli
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Victor Kuarsingh
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Fred Baker
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Victor Kuarsingh
- Re: [v6ops] Reasons not to endorse NAT66/6to4(ref… Rémi Després