Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Alexandru Petrescu <> Mon, 23 February 2015 12:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BA63B1A1A73 for <>; Mon, 23 Feb 2015 04:17:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.983
X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3oqaDsLAjFOI for <>; Mon, 23 Feb 2015 04:17:02 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EAA21A1A72 for <>; Mon, 23 Feb 2015 04:17:02 -0800 (PST)
Received: from ( []) by (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NCGx3O006588 for <>; Mon, 23 Feb 2015 13:16:59 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id CC3E3202CEF for <>; Mon, 23 Feb 2015 13:18:10 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id C4AD1200CF8 for <>; Mon, 23 Feb 2015 13:18:10 +0100 (CET)
Received: from [] ( []) by (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NCGwDU011440 for <>; Mon, 23 Feb 2015 13:16:59 +0100
Message-ID: <>
Date: Mon, 23 Feb 2015 13:16:58 +0100
From: Alexandru Petrescu <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
References: <> <> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
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: Mon, 23 Feb 2015 12:17:04 -0000

Le 23/02/2015 09:09, Lorenzo Colitti a écrit :
> On Mon, Feb 23, 2015 at 4:59 PM, <
> <>> wrote:
> NEW:
> *  If the requested IPv4v6 PDP-Context is not supported by the
> network, but IPv4 and IPv6 PDP types are allowed, then the cellular
> host will be configured with an IPv4 address or an IPv6 prefix by the
> network.  It must initiate another PDP-Context activation in addition
> to the one already activated for a given APN (Access Point Name). The
> purpose of initiating a second PDP-Context is to achieve dual-stack
> connectivity by means of two PDP-Contexts.

> Operators who have deployed IPv6 report that running dual-stack over
>  two PDP contexts is a very bad idea because it consumes 2x the
> network resources.

So this means it would be good to rather recommend one PDP context with
two types on at the same time?  (v4v6).  If so, I would agree.

> Please don't recommend this unless you have evidence that this works
> well in production (not in testing).

I don't think it is possible to have two PDP connections with two APNs 
up at the same time, in the same smartphone.  I have never seen it, is 
it there somewhere?

> NEW: Note, a cellular host changing its connection between an
> IPv6-specific APN and an IPv4-specific APN will interrupt associated
>  network connections.  This may be considered as a brokenness
> situation for some applications.
> What is the purpose of this text? Mobile nodes change IP addresses
> all the time (e.g., when switching from 4G to wifi). How is this
> different?

The switching between two interfaces (4G and wifi) is smoother than
switching a single interface from one APN to another.

For the former, there are many operations taking place simultaneously
(associate, set up PDP, acquire address, establish def route).  Because
of this simultaneity, and because overlapping coverage of 4G/wifi
deployments, very often the end user does not notice any interruption in
the ongoing applications; especially those buffered, or relying on brief
http requests, or restartable TCP sessions, or those perioridally
heartbeating: a youtube session will advance on green line (buffer)
instead of red (live), HTTP HTML pages will display more or less, FTP
transfers will restart by themselves somehow, and the skype check will
re-green.  On another hand, a skype ongoing call _will_ be interrupted.

For the latter, the switching is more brutal: the smartphone must put
interface down and delete routes before putting it up again, new
address, new routes.  There is no simultaneity.  In this case the
socket data structures proper often vanish, and lead to popping up
messages like "you have been disconnected, try again".

Switching between APNs is more brutal even than 'roaming' between two

Beside this app continuity factor, there are more reasons to _not_
recommend switching between APNs, that we could discuss separately.


> _______________________________________________ v6ops mailing list