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

Ross Chandler <ross@eircom.net> Mon, 11 August 2014 07:26 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 72F0D1A0353 for <v6ops@ietfa.amsl.com>; Mon, 11 Aug 2014 00:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level:
X-Spam-Status: No, score=-2.566 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.668] 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 TGDEKw3eU6P3 for <v6ops@ietfa.amsl.com>; Mon, 11 Aug 2014 00:26:47 -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 907861A0350 for <v6ops@ietf.org>; Mon, 11 Aug 2014 00:26:46 -0700 (PDT)
Received: (qmail 36373 messnum 5485650 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 11 Aug 2014 07:26:44 -0000
Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail09.svc.cra.dublin.eircom.net (qp 36373) with SMTP; 11 Aug 2014 07:26:44 -0000
Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id dKSg1o00K0mJ9Tz01KSjVy; Mon, 11 Aug 2014 08:26:44 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_194EFC56-B9BC-4158-B04A-89DBD9C4ECD8"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ross Chandler <ross@eircom.net>
In-Reply-To: <A39A706D-0FC2-4A87-930C-C06AD93D423A@gmail.com>
Date: Mon, 11 Aug 2014 08:26:35 +0100
Message-Id: <016DA482-E7B0-47BE-B15A-8B9D11A21E87@eircom.net>
References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <DE860EBC-171E-46E7-A3B6-5E8B79A453CC@cisco.com> <53DFEC6C.3010707@gmail.com> <CAD6AjGRUWxT5XiNxMi_S5VgYtGMLb_FVHXN-ZfGpcY=geix15g@mail.gmail.com> <53E06AC9.9010908@fud.no> <CAD6AjGTwt-20gXs=RUH5zbhT+g3HKrvXHX3FnShjF1srqU21Fw@mail.gmail.com> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <alpine.DEB.2.02.1408060856080.7929@uplift.swm.pp.se> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> <CAD6AjGTjYTzDRC_UbmmwiafAYch-VH=_sOaMWu+tMOQNrcEOCQ@mail.gmail.com> <DB26AAFC-084D-46D6-BBF5-E5C20B5857AF@eircom.net> <CAD6AjGQUKP8AkYLsq8PjWWUac9163SeUn4tO1fyWLJC8rsF12Q@mail.gmail.com> <A39A706D-0FC2-4A87-930C-C06AD93D423A@gmail.com>
To: Geir Egeland <geir.egeland@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BvwO6s6cMiszf8itY_hKKL-DnGI
Cc: Tore Anderson <tore@fud.no>, IPv6 Ops WG <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: Mon, 11 Aug 2014 07:26:49 -0000

On 11 Aug 2014, at 07:14, Geir Egeland <geir.egeland@gmail.com> wrote:

> So let me try to shed some light on what we are thinking in Telenor Norway.
> 
> Even though we have launched an IPv6-only APN, our main strategy for the home network is to support the Ext. PDP type. Also, both our fixed and mobile network architectures are based on DS.
> 
> We are currently working on putting the final pieces together for enabling DS. Roaming brokeness caused by the ext. PDP is a major concern for us. DS will affect our whole customer base, so it will take a while with testing before we are comfortable launching this.
> 
> Telenor Norway has been piloting NAT64/464XLAT for some time now with no major issues. We see that we need to support all scenarios for mobile devices, i.e. IPv4-only, IPv6-only and DS. We chose to launch IPv6 on a few selected devices as a gradual introduction of IPv6 in our mobile network. 
> 
> By enabling IPv6-only on a few handsets, we can identify those mobile operators that do not support IPv6-roaming and we use this opportunity to contact them through commercial and technical channels, urging them to enable IPv6 support on their SGSN. If this is unsuccessful, we will consider steering the roaming traffic away from those operators during a transition period if necessary.
> 
IMHO this will really help the IPv6 community as it provides an easy to understand message for the business on why we need to enable IPv6 in the user plane for visitors.

The draft should probably mention this risk of being steered away from by an operator that wants IPv6. At the moment the draft just mentions this in the context of the home operator’s own business steering traffic to an operator that doesn’t support IPv6 in the user-plane. 

On enabling IPv6 in the user plane the draft currently says “it’s expected that visited network is IPv6 roaming friendly to enable the functions on SGSN/MME by default”.
Do operators with it on, have it enabled for all IMSI series or do it by IMSI series? I’d like to turn it on by default for all.

> We believe it is important to take an active stand on this instead of waiting for everyone to get around to enable IPv6. As many people on the mailing list have mentioned, there are cases where roaming on IPv6 fails. This is also our experience, but it is something we are willing to accept. 
> 
> As Tore has mentioned, our customers are free to use one of our IPv4-only APNs, however, we have not had any such requests.
> 
> BR,
> 
> Geir Egeland
> Telenor Group/Telenor Norway


BR 
Ross