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

<mohamed.boucadair@orange.com> Mon, 23 February 2015 08:39 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 89CE21A037E for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 00:39:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Asuy3W4PwqHH for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 00:39:07 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622421A00B8 for <v6ops@ietf.org>; Mon, 23 Feb 2015 00:39:06 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id BBEE826418D; Mon, 23 Feb 2015 09:39:04 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 891D435C110; Mon, 23 Feb 2015 09:39:04 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%35]) with mapi id 14.03.0224.002; Mon, 23 Feb 2015 09:39:03 +0100
From: <mohamed.boucadair@orange.com>
To: Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Thread-Index: AQHQT0AawS1TrvK5xEGzvJUswqnHoJz954Ww
Date: Mon, 23 Feb 2015 08:39:02 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <alpine.DEB.2.02.1502201513320.4007@uplift.swm.pp.se> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAKD1Yr3A6fzgTauLz+Yxe-xOLeDLZ5bzKBo-XyWU4i9LBSAM9Q@mail.gmail.com>
In-Reply-To: <CAKD1Yr3A6fzgTauLz+Yxe-xOLeDLZ5bzKBo-XyWU4i9LBSAM9Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049122B6OPEXCLILM23corp_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.112421
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/x3iDXW5z95bly-seefcODSvuAVM>
Cc: V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
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, 23 Feb 2015 08:39:09 -0000

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:lorenzo@google.com]
Envoyé : lundi 23 février 2015 09:09
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mikael Abrahamsson; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Mon, Feb 23, 2015 at 4:59 PM, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> 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. 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
                PDP-Contexts.

             *  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
             devices.



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?

[Med] This text was added to address a comment from Alex. I will let him further clarify, but Alex is asking for APNs that are not specific to a given address family, hence this note.