Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Michael Newbery <newbery@gmail.com> Tue, 19 April 2011 21:30 UTC

Return-Path: <newbery@gmail.com>
X-Original-To: v6ops@ietfc.amsl.com
Delivered-To: v6ops@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B46DEE06DE for <v6ops@ietfc.amsl.com>; Tue, 19 Apr 2011 14:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.032
X-Spam-Level:
X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaZUo1XWqfWd for <v6ops@ietfc.amsl.com>; Tue, 19 Apr 2011 14:30:53 -0700 (PDT)
Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id A4C43E06BE for <v6ops@ietf.org>; Tue, 19 Apr 2011 14:30:53 -0700 (PDT)
Received: by pxi20 with SMTP id 20so92530pxi.27 for <v6ops@ietf.org>; Tue, 19 Apr 2011 14:30:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=/qc95AQDIO5qQfF5kVjByUZoUMOfeyERog394cF3vQ8=; b=UY30elzfBHc6X3vU/A/8yew/TjDEBaTqTT8IRVFm8pYRY1B1W5ZnXihvHGT7/99kQu JCgtjApb4XJpEz38IaRo9v3z78L23UnOlOacm0QwkQHfydjwp0169mDc0zShrFNAb9Sm /I7p5iXEuYparQ+TcoK9r5n74mRngQ2ZJzZdE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=p+SKB9GDwix5PQ5JyR7rlxtMtDHVNrQgJIRvXKaUC/nqi4eLwzszrvkPhVnwkV8ehC Jz5cPmh1feaoejN1gi6a+oZP31WwCvUiVXzw4+BdywP16aNK6sTy/uR6V8yF1uGtDUWR 2V9Ap/oTsH5XHEgjOkU0BgP6c1QyWgxOPqK4o=
Received: by 10.68.33.42 with SMTP id o10mr9304028pbi.90.1303248653102; Tue, 19 Apr 2011 14:30:53 -0700 (PDT)
Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id u3sm177791pbh.8.2011.04.19.14.30.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 14:30:51 -0700 (PDT)
From: Michael Newbery <newbery@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary="Apple-Mail-2-671413953"; protocol="application/pkcs7-signature"; micalg="sha1"
Date: Wed, 20 Apr 2011 09:30:40 +1200
In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com>
To: IPv6 Ops WG <v6ops@ietf.org>
References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com>
Message-Id: <E4BC3273-F288-4AC1-A1B5-9FB630C52E07@gmail.com>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 19 Apr 2011 21:30:54 -0000

On 20/04/2011, at 6:22 AM, George, Wes E IV [NTK] wrote:

> 
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt
> 

> Also, most consumer ISPs have the excuse that too many of their provider-provisioned CPE gateways do not support native IPv6
> routing.
> ______
> [WEG] There is a solution for that, and it's not 6to4. 6rd is one option if it's actually the provider's CPE infra (modems,
> DSLAM/CMTS) that doesn't support IPv6. If it's the CPE router (which may be customer-owned) that doesn't support IPv6, the solution
> is for the CPE gateway vendors to provide software updates with IPv6 support to ALL of their hardware regardless of age unless it's
> technically impossible on a given device, so that operators aren't limited to the single option of "sorry, you'll have to replace
> your equipment" in order to roll out IPv6 widely. This is *especially* true for devices which support 6to4 but not native IPv6
> today. 

My discussions with vendors however indicate that in general it IS technically impossible. Certainly there is a large amount of gear out there that has no IPv6 support, not even 6to4. This is generally made very cheaply, usually based on a reference design or chipset and using firmware and operating system provided by the chipset manufacturer. The OEM adds a little value, but mostly they have no ability to add significant extra functionality. It is likely for instance that there is just insufficient memory to add native IPv6 support. At the low end, only very recent equipment has sufficient capacity. I know of one low end CPE vendor that is adding all the right stuff, and their most recent gateway CAN be upgraded. But their previous model simply lacks the ability (in their opinion).

Furthermore, getting most CPE gateway vendors to expend the considerable effort---and money---to enable native IPv6 support on their already sold hardware would bring them in how much revenue?

The CPE situation may be shameful, and one might be justifiably grumpy with (most of) the CPE vendors for not having shipped suitable equipment for YEARS now, but dealing with the world as it is, I don't see any realistic alternative for most customers who own their own RGs apart from having to buy new ones. 

Where the provider supplies the gateway, it is the provider who is faced with the prospect of physically replacing hundreds of thousands of pieces of equipment. Apart from the cost of the equipment, the cost of the truck rolls will cause the CFO to go pale. Again, the provider SHOULD have chosen better equipment, assuming that it was in fact available (in practice, it wasn't, because enough of the SPs didn't insist on it, so the CPE manufacturers didn't do it), but regardless, this is the situation faced by many providers. We can argue about how we got into this situation: I'm only interested in figuring out how we get out of it.