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

Ross Chandler <ross@eircom.net> Fri, 20 February 2015 12:22 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 2D5A21A1E10 for <v6ops@ietfa.amsl.com>; Fri, 20 Feb 2015 04:22:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.992
X-Spam-Level:
X-Spam-Status: No, score=0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 VuCpI1p3nI1K for <v6ops@ietfa.amsl.com>; Fri, 20 Feb 2015 04:22:02 -0800 (PST)
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by ietfa.amsl.com (Postfix) with SMTP id BBC2E1A19F7 for <v6ops@ietf.org>; Fri, 20 Feb 2015 04:13:28 -0800 (PST)
Received: (qmail 42881 messnum 12642051 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 20 Feb 2015 12:13:27 -0000
Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail06.svc.cra.dublin.eircom.net (qp 42881) with SMTP; 20 Feb 2015 12:13:27 -0000
Received: from [IPv6:2a01:b340:20:1e59:2866:ce57:ba06:4a8a] ([185.51.73.206]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id ucDP1p00G4T2iB501cDT1K; Fri, 20 Feb 2015 12:13:27 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_BDDD3050-C962-4A32-8B1E-69D9D100484E"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ross Chandler <ross@eircom.net>
In-Reply-To: <A0BB7AD89EA705449C486BDB5FDCBC7B28512185@OPE10MB06.tp.gk.corp.tepenet>
Date: Fri, 20 Feb 2015 12:13:24 +0000
Message-Id: <EE1BBA27-ECD0-475B-A42D-406FB4BF795A@eircom.net>
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> <A0BB7AD89EA705449C486BDB5FDCBC7B2 8512185@OPE10MB06.tp.gk.corp.tepenet>
To: Kossut Tomasz - Hurt <Tomasz.Kossut@orange.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/cUxr-K37xgQ9oWXm157oUQ1didU>
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 12:22:05 -0000

It’s unfortunate this wasn’t captured in the roaming-analysis I-D. IMHO it looks like that operators must try harder to sort out their networks and billing mediation systems so IPv6 roaming is allowed.

Ross


> On 20 Feb 2015, at 11:09, Kossut Tomasz - Hurt <Tomasz.Kossut@orange.com> wrote:
> 
> 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 <mailto:jouni.nospam@gmail.com>] 
> Sent: Thursday, February 19, 2015 9:31 PM
> To: Ross Chandler
> Cc: Alexandru Petrescu; v6ops@ietf.org <mailto: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