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

Dave Michaud <> Mon, 23 February 2015 13:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9C0A71A1A9F for <>; Mon, 23 Feb 2015 05:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BQLcYdG1oOhh for <>; Mon, 23 Feb 2015 05:25:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B0D91A0021 for <>; Mon, 23 Feb 2015 05:25:53 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 23 Feb 2015 13:25:51 +0000
Received: from ([]) by ([]) with mapi id 15.01.0093.004; Mon, 23 Feb 2015 13:25:51 +0000
From: Dave Michaud <>
To: "" <>, "Lorenzo Colitti" <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Date: Mon, 23 Feb 2015 13:25:51 +0000
Message-ID: <>
References: <> <> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup>
Accept-Language: en-CA, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
authentication-results: spf=none (sender IP is );
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0401MB1067;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0401MB1067;
x-forefront-prvs: 0496DF6962
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(24454002)(377454003)(19273905006)(19300405004)(101416001)(19625215002)(92566002)(77156002)(62966003)(2900100001)(16236675004)(19617315012)(2950100001)(86362001)(66066001)(1720100001)(87936001)(40100003)(102836002)(15975445007)(122556002)(68736005)(2656002)(93886004)(83506001)(19580405001)(19580395003)(46102003)(54356999)(99286002)(97736003)(76176999)(230783001)(106116001)(2501002)(106356001)(64706001)(105586002)(50986999)(74826001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0401MB1067;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_D11092F81AD6Edavemichaudrcirogerscom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2015 13:25:51.4997 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0ab4cbbf-4bc7-4826-b52c-a14fed5286b9
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1067
Archived-At: <>
Cc: V6 Ops List <>
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 13:25:56 -0000

To further clarify the comment below, this is not a recommendation but it is the expected behaviour as per the 3GPP spec.

Upon receiving a request for a dual-stack PDP, the network operator can return one of the following cause codes (there are a lot more options but these are the relevant ones for discussion):

Cause code 50: PDP Type IPv4 only allowed
Cause code 51: PDP Type IPv6 only allowed
Cause code 52: Single address bearers only allowed

In the first 2 causes (CC50 & CC51), the UE is to accept the PDP type selected by the network (IPv4 or IPv6) and not proceed further. Cause code 52 is the mean by which the network signals that it will allow two distincts PDP of different address type. In that case only is the UE suppose to go back and request a second PDP with the alternate type not offered by the network at the same time cause code 52 was returned.

"If the requested IPv4v6 PDP-Context is not supported by
the network, but IPv4 and IPv6 PDP types are allowed…” —> This is signalled with cause code 52.

Dave Michaud
Sr. Architect Mobility – Access Networks & IP Network Services
Network Technology | Rogers Communications<> | tel: +1 647.747.9442 | mobile: +1 416.219.5531

From: "<>" <<>>
Date: Monday, February 23, 2015 at 07:10
To: Lorenzo Colitti <<>>
Cc: IPv6 WG <<>>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call


Please see inline.


De : Lorenzo Colitti []
Envoyé : lundi 23 février 2015 11:49
Cc : Mikael Abrahamsson; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Mon, Feb 23, 2015 at 5:39 PM, <<>> wrote:
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. Please don't recommend this unless you have evidence that this works well in production (not in testing).

[Med] We are not recommending establishing systematically two PDP contexts. Please check the full recommendation provided below for your convenience.

   C_REC#2:  The cellular host must comply with the behavior defined in
             [TS.23060] [TS.23401] [TS.24008] for requesting a PDP-
             Context type.  In particular, the cellular host must
             request by default an IPv6 PDP-Context if the cellular host
             is IPv6-only and request an IPv4v6 PDP-Context if the
             cellular host is dual-stack or when the cellular host is
             not aware of connectivity types requested by devices
             connected to it (e.g., cellular host with LAN capabilities
             as discussed in Section 3):

             *  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

How are you "not recommending" this behaviour, if the text says that the device "must initiate another PDP-Context activation"?

[Med] It seems you skipped “systematically” in my answer ;-). So, I confirm “we are not recommending establishing systematically two PDP contexts”. The default behavior is to ask for a IPv4v6 PDP-Context, but (1) if the IPv4v6 PDP-Context is not supported, and (2) if IPv4 and IPv6 PDP types are allowed, two PDP contexts can be requested. The network is free to accept those or not. As you can see there are “if”s in this behavior. So to be accurate, this text does not recommend requesting two separate PDP contexts as default behavior, but it does not forbid it either.

             *  If the subscription data or network configuration allows
                only one IP address family (IPv4 or IPv6), the cellular
                host must not request a second PDP-Context to the same
                APN for the other IP address family.

             The text above focuses on the specification part which
             explains the behavior for requesting IPv6-related PDP-
             Context(s).  Understanding this behavior is important to
             avoid having broken IPv6 implementations in cellular

I find this last paragraph meaningless. What is it intended to convey?

[Med] FWIW, the last paragraph was added as per a comment received from the mailing list: The point is that the set of cited specifications contains more details about how PDP contexts are to be handled compared to what is described in here (that is IPv6-sepcific).

This communication is confidential. We only send and receive email on the basis of the terms set out at<>

Ce message est confidentiel. Notre transmission et réception de courriels se fait strictement suivant les modalités énoncées dans l’avis publié à <>