Return-Path: 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 6EBD61A036C for ; Mon, 16 Feb 2015 17:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XMr53zN_k1DL for ; Mon, 16 Feb 2015 17:57:57 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686A31A6FF3 for ; Mon, 16 Feb 2015 17:57:57 -0800 (PST) Received: by iecvy18 with SMTP id vy18so37812805iec.6 for ; Mon, 16 Feb 2015 17:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p/BZgXU854uARh5789v3k994q/cQ78f0ND8xD59fg4Q=; b=WMr6povVha9GXfS7Cl4XiZnYrNkaXVWqRvK1u2Zo1juCc36vV9+p0dD7lJyecFNv3e 74PDOiEk7NpqEYPSj/WEgn8CUDjveWxsQZbPL2OWBMaYiS5qoxxuCGqPYRsIxHXR1Fpa B1tgVU5wDvjyb6bSbbqzhdR6Warfa4Apl5pjV57D4x5q5GNrQjdM3QjZkE+lRIk9QvBs DQgQIonGchfw3gl2ch1FXrRjUcPNhnXb1c+3nYTedTQftHIsXCjlC8FK29frIxCbnPcB /Ps+jBS+rdR8pcx/ZbU7SirZOkt2duuIH3b+APixMsq3aX/lvzgQhYrH5+3VmowU90dr i3fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p/BZgXU854uARh5789v3k994q/cQ78f0ND8xD59fg4Q=; b=kz3yM84FsLLPOxjE7sGzLytxo8h7DfiFosdyX/vlL7asAw3XRiLtsBkAMtzr/B8prF U8wxxrKhZ5c7MoVKWbVmedEiX4gcv6sYik1UdgdOInZVlSgNi8QBwPYqtwrSCXusN0JN M73x++7+T79l7JKY7zEirY+Txpcr0fsVuZzpkfQpW56cOFbuqq0+oWmIEP8vprJRyYc7 VX1Tgi/XwEiSyoAFRFdsbqVSFqLXlQl17QaTEJsMWu5uu3Cg1ax5+GaANwS43EbsEps1 24bhrh+jMWiDDZcV1AU2xAb0rYhk83fcCqk3mqoQGAoCa3DB5wSFsm26uKmuFu2hrHy1 QIVw== X-Gm-Message-State: ALoCoQnyi5EoYkV+mHJoj+lMT4XcYrbk9FMJlxy3G7EnhOYSoWA8LhbxK6RSqN6f+4/uGyyuwivL X-Received: by 10.43.79.129 with SMTP id zq1mr13120844icb.28.1424138276763; Mon, 16 Feb 2015 17:57:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 16 Feb 2015 17:57:36 -0800 (PST) In-Reply-To: <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Lorenzo Colitti Date: Tue, 17 Feb 2015 10:57:36 +0900 Message-ID: To: "Heatley, Nick" Content-Type: multipart/alternative; boundary=001a11332018191c4b050f3f082b Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 01:57:59 -0000 --001a11332018191c4b050f3f082b Content-Type: text/plain; charset=UTF-8 On Mon, Feb 16, 2015 at 6:23 PM, Heatley, Nick wrote: > Lorenzo, > > Focusing on a) what do you suggest? > > Have you another way? > Yes. Make IPv6* (see below) a requirement for carrier-branded devices, and give the OEMs a credible signal that from date X onwards, you *will* fail TA on every device that doesn't implement IPv6, and you *will not* waive the requirement. That's what Verizon and T-Mobile did, and it worked for them. It's true that T-Mobile and Verizon have more market power than some of the carriers that are behind this draft. However, they definitely do not have more market power than all the carriers behind this draft taken together. Also, when they put those requirements down, IPv6 support in mobile devices was in a much worse state; some devices didn't implement it at all, and some had pretty severe bugs. Today, any OEM that sells to T-Mobile or Verizon must have an IPv6 stack that's high-enough quality that tens of millions of users can use it. So the problem you need to solve is easier than the one they needed to solve; all you need to do is ask them not to disable IPv6 in the European firmware, just like it's not disabled in the US firmware. If your problem is that you want to go directly from IPv4-only to IPv6-only, but you feel that you can't do that because iOS doesn't support 464xlat, then you're in the same boat as T-Mobile. And in fact, I believe that their requirement is something along the lines of "if your device runs an operating system that supports 464xlat, you MUST configure your device as IPv6-only with 464xlat" (which is roughly equivalent to saying, "you must do 464xlat unless you're Apple"). That has a lot of value, because whatever percentage of your users are on Android or Windows Phone won't consume IPv4 addresses. The public statistics say T-Mobile is close to 50% devices running IPv6-only. That's a lot IPv4 addresses saved. Over time, the more operators take this position, the more will be using 464xlat, and eventually even Apple will read the writing on the wall and implement it. They're free to use the Android implementation; it's Apache-licensed. The disappointed for me in the discussion about this common reqts paper is > not that there are a few strong voices rejecting this initiative. > > It is that there are no voices of support. As I think you have pointed > out, there is little support beyond the authors. > Personally, I think the resistance/lack of support is mostly due to the fact that it is not the IETF's job to dictate/influence which technologies are used in the Internet. The IETF's job is to specify those technologies, but that's already been done. --001a11332018191c4b050f3f082b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 16, 2015 at 6:23 PM, Heatley, Nick <nick.heatley@ee.co.uk&= gt; wrote:

Lorenzo,

Focusing on a) what do you suggest?

Have you another way?

=

Yes. Make IPv6* (see below) a requirement = for carrier-branded devices, and give the OEMs a credible signal that from = date X onwards, you *will* fail TA on every device that doesn't impleme= nt IPv6, and you *will not* waive the requirement. That's what Verizon = and T-Mobile did, and it worked for them.

It's= true that T-Mobile and Verizon have more market power than some of the car= riers that are behind this draft. However, they definitely do not have more= market power than all the carriers behind this draft taken together. Also,= when they put those requirements down, IPv6 support in mobile devices was = in a much worse state; some devices didn't implement it at all, and som= e had pretty severe bugs. Today, any OEM that sells to T-Mobile or Verizon = must have an IPv6 stack that's high-enough quality that tens of million= s of users can use it. So the problem you need to solve is easier than the = one they needed to solve; all you need to do is ask them not to disable IPv= 6 in the European firmware, just like it's not disabled in the US firmw= are.

If your problem is that you want to go direct= ly from IPv4-only to IPv6-only, but you feel that you can't do that bec= ause iOS doesn't support 464xlat, then you're in the same boat as T= -Mobile. And in fact, I believe that their requirement is something along t= he lines of "if your device runs an operating system that supports 464= xlat, you MUST configure your device as IPv6-only with 464xlat" (which= is roughly equivalent to saying, "you must do 464xlat unless you'= re Apple"). That has a lot of value, because whatever percentage of yo= ur users are on Android or Windows Phone won't consume IPv4 addresses. = The public statistics say T-Mobile is close to 50% devices running IPv6-onl= y. That's a lot IPv4 addresses saved.

Over tim= e, the more operators take this position, the more will be using 464xlat, a= nd eventually even Apple will read the writing on the wall and implement it= . They're free to use the Android implementation; it's Apache-licen= sed.

=

The disappointed for me in the discussion ab= out this common reqts paper is not that there are a few strong voices rejec= ting this initiative.

It is that there are no voices of support. A= s I think you have pointed out, there is little support beyond the authors.=


Personally, I think= the resistance/lack of support is mostly due to the fact that it is not th= e IETF's job to dictate/influence which technologies are used in the In= ternet. The IETF's job is to specify those technologies, but that's= already been done.
--001a11332018191c4b050f3f082b--