Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-02.txt

Ross Chandler <ross@eircom.net> Tue, 05 August 2014 07:20 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 901D01B28D7 for <v6ops@ietfa.amsl.com>; Tue, 5 Aug 2014 00:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 jwqEYkdtgrAQ for <v6ops@ietfa.amsl.com>; Tue, 5 Aug 2014 00:20:28 -0700 (PDT)
Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by ietfa.amsl.com (Postfix) with SMTP id 9EA711B2877 for <v6ops@ietf.org>; Tue, 5 Aug 2014 00:20:26 -0700 (PDT)
Received: (qmail 24470 messnum 5467988 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 5 Aug 2014 07:20:23 -0000
Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail01.svc.cra.dublin.eircom.net (qp 24470) with SMTP; 5 Aug 2014 07:20:23 -0000
Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id avLL1o00V0mJ9Tz01vLPpi; Tue, 05 Aug 2014 08:20:23 +0100
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ross Chandler <ross@eircom.net>
In-Reply-To: <alpine.DEB.2.02.1408041827340.7929@uplift.swm.pp.se>
Date: Tue, 05 Aug 2014 08:20:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <13BBB964-B83A-4721-AA31-68FCC8444AA0@eircom.net>
References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <CAM+vMETtTvs9oeNtg5T7ReyyH1o3g7VXtpG+g-3bKbm6dpAoEQ@mail.gmail.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> <alpine.DEB.2.02.1408041827340.7929@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/88Im3bGZhK1vegMrz3mMlI0jnGw
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-02.txt
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, 05 Aug 2014 07:20:31 -0000

On 4 Aug 2014, at 17:31, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> My opinion is not that any part of the standard is the problem, but rather buggy implementations.

Fair enough, whether through lazy/buggy implementations or a real gap, the resulting network reality requires significantly most commitment to IPv6 deployment from the mobile operator.
We have to make a not particularly paletable choice because of it, getting capex approval for spending on proprietary workarounds or deploy only on Android.

>> e.g. New HLR/HSS functionality to by default restrict the sending PDP-Ext-Type/IPv4v6 with a whitelist of known good networks. Also the complement the default allow sending of PDP-Ext-Type/IPv4v6 with a network blacklist.
> 
> These are operational requriements, and I fully support putting them in some kind of document, but the question is if it's really "roaming analysis" anymore. The language would need to be very careful not to make any recommendations then (?), but rather suggest possible ways of working around the problems seen.

Something like my above sentence could go into it as an observation. Analysis’s can have observations that stop short of being recommendations.

>> Section 7, discussions,  says “dual-stack deployment is recommended in most cases”.
>> Is that still the consensus position?  Going straight to single-stack IPv6 is looking very viable now
>> when the UE supports a method of providing translated IPv4 access over the IPv6 PDP/PDN
>> connection.
> 
> I don't think there is consensus here. The draft could point out pros and cons with each approach.

Fred has generalised the scope of my question beyond 3GPP with an agenda for what might be required to update the consensus. I think the question is too broad for this draft.
Focusing on the mobile case, where there's near ubiquitous RFC1918/RFC6598 use to get to the provider NAT44, replacing that with IPv6 to get the legacy NAT64 gateway seems like such a compelling case that the one size fits all dual-stack recommendation is no longer fit for purpose.

Ross