ietf
[Top] [All Lists]

Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

2014-10-09 10:03:42


On 8 Oct 2014, at 14:52, Kossut Tomasz - Hurt 
<Tomasz(_dot_)Kossut(_at_)orange(_dot_)com> wrote:

Hi,
Majority of modern smartphones from Sony, HTC, LG, Samsung, Nokia WP8.1 are 
compliant with CLAT+NAT64/DNS/DNS64
Together with Michał Czerwonka we created document with mandatory IPv6 
requirements, close cooperation with vendors succeeded and we managed to 
launch first terminal (Xperia Z1) in September 2013, after 12 months we have 
13% of IPv6 only mobile users in a network. If you are mobile operator and 
you thinking about IPv6 migration you won’t have any problems with 
Smartphones (except Iphones=NO CLAT support) the way is paved for you...
 
Network Configuration (CLAT+NAT64+DNS)
Internet access is done by establishing one dedicated IPv6-only PDP/PDN 
context, network supports 464xlat architecture with DNS Dual-Stack (DNS64 
feature is available only for domain “ipv4only.arpa”) - RFC 6877. CLAT 
implementation is mandatory for all devices
 
UE, CPE vendor IPv6 mandatory requirements
2.1.Dynamic IPv6 Address Allocation + IID randomly generated (privacy 
address) +  UE shall use the IID given in PDP activation response message to 
configure its LLA (3GPP TS  
23.060)http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/.

2.2.Customer Side Translator function (CLAT) must be embedded 
(smartphone/tablet/router) as part of 464xlat architecture  RFC 6877. The 
CLAT must support ICMP, UDP, TCP, GRE and fragmented packet. clatd.conf  - 
may be generic where the domain for nat64 prefix discovery must be 
“ipv4only.arpa” –  static configuration may be required.

https://android.googlesource.com/platform/external/android-clat/
2.3.MTU size & device interfaces - If the network send MTU size in RA 
message, then device must set it to the radio interface otherwise set the 
default value=1500B. The CLAT demon will calculate MTU size automatically for 
its interfaces (clat and clat4).

IPv6 tethering - the CLAT helps Dual Stack tethering solution both USB/WIFI 
on the device , when APN is IPv6-only. The Global IPv6 and private IPv4 
(clat) must be enabled on tethered LAN.
http://tools.ietf.org/html/rfc7278 (scenario 2)
3.1.RA – device sends RA message to tethered host with Ipv6 prefix 
information. Router lifetime set=9000 secs. Router sends periodically RA 
message – max. value 9000 secs.

3.2.DHCPv6 – device server relays PCO Ipv6 DNS'es addresses to tethered hosts.

3.3.DHCPv4 – device server relays  private IPv4 address and send DNS IPv4 
(CLAT DNS-proxy)

3.4.Tethering & MTU size – device propagates MTU size 1500B to tethered 
clients interfaces ( Ipv4&Ipv6)

IPv6 LTE UE  - the device must set EIT bit=1 in “Initial Attach” message.
Roaming - when APN with IPv6 protocol fails in roaming it must automatically 
revert back APN protocol to IPv4

Hi Tomasz,

Nice post.

Regarding the EIT bit=1, are all the above vendors setting that or any not 
setting it? I haven’t had to explicitly request that in any of the smartphone 
UEs I’ve tested. It just worked. 

Is the automatic fallback, when roaming, from APN protocol IPv6 to APN protocol 
IPv4 when there’s a problem with IPv6 something you _already_ have with your 
UEs or a desired behaviour? 
I don’t see fallback to IPv4 when the network or HLR/HSS denies IPv6. The RIL 
only fallbacks from IPv4v6 to IPv4, or parallel IPv4 and IPv6. 

BR
Ross

One thing is still missing – different APN profiles(APN name+PDP type) for 
roaming –, there are two use cases:
Euinterent – (“EU Roaming Regulation III”) Internet APN available in UE 
countries (VPLMN subscriber is allowed to use VGGSN APN)
“Roaming Fallback to IPv4” creating separate roaming profile with APN 
name/PDP (now roaming fallback is based only on PDP type Android4.x/WP8.1)
 
Here are the benefits of extending APN profiles:
 
-       APN profiles and its “zones” HPLMN/VPLMN can separate IPv6 form IPv4
-       Separate APN for HPLMN (Ipv6 only APN for HPLMN)
-       Separate  APN for VPLMN roaming (fallback to IPv4 based on APN name)
-       Euinternet APN as secondary roaming profile for manual selection
 
Best Regards,
Tomasz Kossut
 
 
From: Heatley, Nick [mailto:nick(_dot_)heatley(_at_)ee(_dot_)co(_dot_)uk] 
Sent: Tuesday, October 07, 2014 11:31 AM
To: Lorenzo Colitti; IETF Discussion
Cc: v6ops(_at_)ietf(_dot_)org WG; IETF-Announce
Subject: Re: [v6ops] Last Call: 
<draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 
6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
 
2. I stand by my earlier assessment that this document's requirements are 
over-broad, and in fact so broad as to harm adoption. There may well be 
operators or device implementers that seeing with such a high number of 
requirements may shy away in terror and think that deploying IPv6 in a mobile 
network is an impossibly high amount of work. That said, given that this 
document says clearly that it is not a standard, and that compliance is not 
required, the harm it does will be limited.
 
There may well be operators and device implementers that see the many 
individual “IPv6” RFCs and shy away. Transitioning technologies are still 
perceived as issues for the network.
If this cross-operator document states what is required on terminals to work 
in all major/predictable IPv6 scenarios, then it is giving such people a view 
of what a “healthy and robust” terminal implementation would consist of. If 
they are able to deliver on these requirements then they can supply a 
terminal ready for all business areas /all operator network scenarios.
(It certainly stops the feedback I’ve had from certain corners “that no other 
operators are asking for IPv6”, and “what you are asking for is a single 
operator roadmap which we won’t do”. That has been the reality here). So I 
don’t see how a consolidated demand-side view from operators who are really 
trying to introduce IPv6  in mobile can harm adoption in any way.
Regards,
Nick
 
 
From: v6ops [mailto:v6ops-bounces(_at_)ietf(_dot_)org] On Behalf Of Lorenzo 
Colitti
Sent: 06 October 2014 08:30
To: IETF Discussion
Cc: v6ops(_at_)ietf(_dot_)org WG; IETF-Announce
Subject: Re: [v6ops] Last Call: 
<draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 
6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
 
 
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named 
person(s).  If you are not the intended recipient, notify the sender 
immediately, delete this email from your system and do not disclose or use 
for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current 
legislation. We have taken steps to ensure that this email and attachments 
are free from any virus, but it remains your responsibility to ensure that 
viruses do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, 
Hertfordshire, AL10 9BW

_______________________________________________
v6ops mailing list
v6ops(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/v6ops

<Prev in Thread] Current Thread [Next in Thread>