IETF Logo Mail Archive

Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

Ross Chandler <ross@eircom.net> Tue, 07 October 2014 13:46 UTC

Return-Path: <ross@eircom.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998711ACDA1 for <v6ops@ietfa.amsl.com>; Tue, 7 Oct 2014 06:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.684
X-Spam-Level:
X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSvuer8d_XEl for <v6ops@ietfa.amsl.com>; Tue, 7 Oct 2014 06:46:40 -0700 (PDT)
Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by ietfa.amsl.com (Postfix) with SMTP id CD9AD1ACD92 for <v6ops@ietf.org>; Tue, 7 Oct 2014 06:46:04 -0700 (PDT)
Received: (qmail 79938 messnum 5385115 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 7 Oct 2014 13:46:03 -0000
Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail09.svc.cra.dublin.eircom.net (qp 79938) with SMTP; 7 Oct 2014 13:46:03 -0000
Received: from [192.168.43.190] ([185.51.73.4]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id 0Dln1p00Y05YtxD01Dm1TN; Tue, 07 Oct 2014 14:46:03 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_3CD2A3E0-4802-4084-A73E-5A9001C164C7"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ross Chandler <ross@eircom.net>
In-Reply-To: <CAKD1Yr0j6c9-Xs27VXqHas_DQjV30iF3fp4AVXKGPs_UXY0+5w@mail.gmail.com>
Date: Tue, 07 Oct 2014 14:45:27 +0100
Message-Id: <6BFD1641-B861-4FBF-852D-E1AF48B97973@eircom.net>
References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <CAKD1Yr2d4f-eJvCbSrdZ7e=m4oCXVhABnT-cVxe16WncqRn9tA@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr0j6c9-Xs27VXqHas_DQjV30iF3fp4AVXKGPs_UXY0+5w@mail.gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/skkHz0dK7sVCrPIRJZao8HLI0UE
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, IETF Discussion <ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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, 07 Oct 2014 13:46:49 -0000

On 7 Oct 2014, at 11:30, Lorenzo Colitti <lorenzo@google.com> wrote:

> On Tue, Oct 7, 2014 at 6:30 PM, Heatley, Nick <nick.heatley@ee.co.uk> wrote:
> If this cross-operator document states what is required on terminals to work in all major/predictable IPv6 scenarios, then it is giving such people a view of what a “healthy and robust” terminal implementation would consist of. If they are able to deliver on these requirements then they can supply a terminal ready for all business areas /all operator network scenarios.
> 
> 
> It depends on your point of view. The way I see it, it’s giving such people a view of what a kitchen sink consists of.

There are a few of these RFCs giving lists.  On the fixed side I ask vendors to support RFC 6092 and RFC 7084 and that starts a dialogue on want we really need for initial deployment. I’ve got spreadsheets back from vendors listing point by point what they support, have road-mapped, don’t plan to support. That’s often fine as I don’t need all the features initially.

> (It certainly stops the feedback I’ve had from certain corners “that no other operators are asking for IPv6”, and “what you are asking for is a single operator roadmap which we won’t do”. That has been the reality here). So I don’t see how a consolidated demand-side view from operators who are really trying to introduce IPv6  in mobile can harm adoption in any way.
> 
> 
> Show me an operator whose rollout is genuinely blocked on terminal features and I will believe you. But word from everyone I've talked to is that terminal features are not the blocker. Operators such as Verizon Wireless and T-Mobile in the US have deployed tens of millions of IPv6-capable devices, and none of those devices (and, I'd argue, no commercial devices, anywhere) implement all the features in this profile. The vast majority only support a handful.

If Apple iOS supported IPv6-only/464xlat and all mobile devices had better support for problem roaming cases then I might think this might not provide a needed signal but it would still be useful to have a document listing desired features.


> The main problem I have with this document is it provides one more excuse to naysayers who believe that IPv6 is hard. The truth is that various operators have built perfectly functioning IPv6 mobile networks which implement only a handful of these features. But if the naysayers see this document, they'll say "See? Told you - IPv6 is so complicated that it will cost us a boatload of money, and it will bring no additional revenue. No point in implementing it.”


The majority of work implementing the appropriate subset of the features is with the mobile device vendor. There’s a growing list of operators to look at that are doing it under restricted circumstances. Items from the list could help operators broaden the scope of their IPv6 deployments.


BR
Ross

v2.23.0 | Report a Bug | By Email