Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD

Kossut Tomasz - Hurt <Tomasz.Kossut@orange.com> Fri, 20 February 2015 11:09 UTC

Return-Path: <Tomasz.Kossut@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 7C1FF1A8848 for <v6ops@ietfa.amsl.com>; Fri, 20 Feb 2015 03:09:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.386
X-Spam-Level: ***
X-Spam-Status: No, score=3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 IqZYvziS2Y9l for <v6ops@ietfa.amsl.com>; Fri, 20 Feb 2015 03:09:44 -0800 (PST)
Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C061A87DB for <v6ops@ietf.org>; Fri, 20 Feb 2015 03:09:42 -0800 (PST)
Received: from 10.236.62.138 (EHLO OPE10HT04.tp.gk.corp.tepenet) ([10.236.62.138]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id DCM37174; Fri, 20 Feb 2015 12:09:30 +0100 (CET)
From: Kossut Tomasz - Hurt <Tomasz.Kossut@orange.com>
To: jouni korhonen <jouni.nospam@gmail.com>, Ross Chandler <ross@eircom.net>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD
Thread-Index: AQHQS3pwxyPvcAyf6kiWrcbrZFHqrJz2jVSAgABDWgCAAY1wgIAA3M+w
Date: Fri, 20 Feb 2015 11:09:29 +0000
Message-ID: <A0BB7AD89EA705449C486BDB5FDCBC7B28512185@OPE10MB06.tp.gk.corp.tepenet>
References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <A0BB7AD89EA705449C486BDB5FDCBC7B2851152A@OPE10MB06.tp.gk.corp.tepenet> <54E1D42C.5040605@gmail.com> <A0BB7AD89EA705449C486BDB5FDCBC7B28511B64@OPE10MB06.tp.gk.corp.tepenet> <54E48C2E.2020703@gmail.com> <CAC8SSWswVfT2KZF-L-TJveszJ5SZn_1xuMvwG_aP2-CHw5erjg@mail.gmail.com> <F40B1638-F988-4B81-8D74-F40AE13ACDA7@eircom.net> <CAC8SSWsh8E8OXLYACktfQEonBDAJ2U5-CcSenvVgG4En0UPhfw@mail.gmail.com>
In-Reply-To: <CAC8SSWsh8E8OXLYACktfQEonBDAJ2U5-CcSenvVgG4En0UPhfw@mail.gmail.com>
Accept-Language: pl-PL, en-US
Content-Language: pl-PL
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [126.20.50.1]
Content-Type: multipart/alternative; boundary="_000_A0BB7AD89EA705449C486BDB5FDCBC7B28512185OPE10MB06tpgkco_"
MIME-Version: 1.0
X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2015.2.20.100022:17:8.510, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __HIGHBITS, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __HTML_FONT_BLUE, __HTML_FONT_RED, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_70_90, WEBMAIL_SOURCE, MULTIPLE_RCPTS, __FRAUD_WEBMAIL, REFERENCES
X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0202.54E715EB.005E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine
X-Junkmail-IWF: false
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0202.54E715EB.005E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: abfd206a7c7b8f55533f98d860d4129c
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/-fZjxMXHboLA2tFgPyl4TILDnXM>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD
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: Fri, 20 Feb 2015 11:09:47 -0000

Hi,
IMHO EIT settings should be part of customization – vendor&generic  controlled by (MCCMNC) just like APN settings it has direct impact in HPLMN on IP (IPv4) allocation.

If network has IPv4 default bearer and EIT bit is not enabled in IPv6 terminals it results in default bearer activation and “selected”(IPv6) bearer activation, IPv6 terminal in a network with IPv4 default bearer will always establish 2 bearers. It’s observed in HPLMN for generic Google devices in our network:
vvvvvv CALLID   MSID            USERNAME               IP                                 TIME-IDLE
------ -------- --------------- ---------------------- ----------------------------- ---------
xTC.AT 0c3a069c 26003000000000 n/a                    2a00:f41:XXXX:XXX::4d1d:7001 00h00m02s
xTC.AI 0c3a069c 26003000000000 n/a                    10.000.000.000  00h00m02s

IPv6 subscriber is allocating unwanted IPv4 resource here - this apply to HPLMN only.

For VPLMN (roaming LTE) situation  gets complicated if you choose to use IPv4 for VPLMN (APN settings - use IPv4 when roaming)
Terminal in LTE with EIT bit=1 located in VPLMN will always request “selected” IPv6 bearer for attach (terminal attaching in LTE has no idea whether this is HPLMN or VPLMN) once terminal learned ”I’m in roaming” according to APN settings(use IPv4 when roaming) terminal will establish secondary IPv4 bearer –it results in multiple bearer activation…

Cheers,
TK



From: jouni korhonen [mailto:jouni.nospam@gmail.com]
Sent: Thursday, February 19, 2015 9:31 PM
To: Ross Chandler
Cc: Alexandru Petrescu; v6ops@ietf.org; Kossut Tomasz - Hurt
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD

I still fail to see how EIT setting relates to IPv6 as a requirement.  It is a normal procedure when the UE wants to connect (during the initial attach) to another APN than the default one.
- Jouni

On Wed, Feb 18, 2015 at 12:48 PM, Ross Chandler <ross@eircom.net<mailto:ross@eircom.net>> wrote:

On 18 Feb 2015, at 16:47, jouni korhonen <jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>> wrote:



On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com<mailto:alexandru.petrescu@gmail.com>> wrote:
Hi,

Le 18/02/2015 12:13, Kossut Tomasz - Hurt a écrit :
Hi,

Inline comments:

Hi,

Thank you for the report. It is good to see how good consideration
is given to IPv6, and the two separated paths IPv4/IPv6.

It is encouraging to see numerous smartphone manufacturers having
embraced the CLAT technology.

(tk) - this is not only CLAT, (CLAT is in generic Android thanks to
Lorenzo, Cameron, Dan & others) each vendor has its own
customization based on MCCMNC/region to control "features" per
operator. In our case we have :  dedicated clatd.conf (not generic
one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS)

It's good to see these mentioned.

For tethering - is the network offering DHCPv6 Prefix Delegation
service?  Or is the device performing '64share' RFC7278?

There are some advantages on doing the former rather than the latter.
EIT bit =1,

What is the EIT bit?

My wild guess is that it is the ESM information transfer flag bit in the ESM information transfer flag information element. If it is, it does not really have anything to do with IPv6 IMHO.
- Jouni

As far as I can tell from a previous answer on v6ops by Orange PL the EIT bit (think it is ESM info transfer flag IE) has an effect when the HSS has a default APN different from the one requested by the UE.  Without the EIT bit set the network doesn’t let the UE requested APN override the default from the HSS, so two PDN connections are set up, one with IPv4 (assuming the default is an IPv4 only APN) and the other IPv6 (assuming that was requested by the UE).  So strictly speaking it does look independent of IP version but it is being noticed as operators introduce IPv6.

Ross