|
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...
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
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).
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)
Roaming - when APN with IPv6 protocol fails in roaming it must automatically revert back APN protocol to IPv4 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.heatley@xxxxxxxx]
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@xxxxxxxx]
On Behalf Of Lorenzo Colitti NOTICE AND DISCLAIMER EE Limited |