|
Lorenzo, I have had another look at the list of reqts you highlight. I find each referencing a valid RFC or 3GPP section, and each explaining the context in which the
reqt is valid. Simply arguing that they do not exist widely today is not reason to discount these. [For your info on privacy extension, the IID is not provided by the network, a temp IID is provided during the attach to the PGW but this is then superseded
by the SLAAC process after the network prefix is learnt via RA. Major handset OS including yours provide temporary addresses with pseudo-random IID.] Regarding DHCPv6 and Prefix Del, then I know of no operator network using this today. However this is the only requirement that a mobile operator can give to
their product marketing people, I feel we would be foolish to lose these. An IPv6 requirement that actually could bring new business
J May I remind you of the objectives set out in section 1 The objectives of this effort are: 1. List in one single document a comprehensive list of IPv6 features for a mobile device, including both IPv6-only and dual-stack mobile deployment contexts. These features cover various network types such as GPRS (General Packet Radio Service), EPC (Evolved Packet Core) or IEEE 802.11 network. 2. Help Operators with the detailed device requirement list preparation (to be exchanged with device suppliers). This is also a contribution to harmonize Operators' requirements towards device vendors. 3. Vendors to be aware of a set of features to allow for IPv6 connectivity and IPv4 service continuity (over an IPv6-only transport). I find the objectives clear and the document goes on to meets those objectives. In this paper both IPv6-only and dual stack are valid, and the reqts that apply to IPv6-only tend to state that; this is an operator choice. As I understand it: Verizon Wireless have achieved their fantastic IPv6 penetration using a dual stack deployment model (perhaps they would therefore argue that 464xlat is only
a “should”). T-Mobile US also have great results with 464xlat on an IPv6-only APN, however tethering/wifi hotspot is via another APN. To provide IPv6-only on a single APN including tethering/Wifi Hostspot is difficult due to breadth of terminal support, including some poor tethering integration
(L_REQ#4 deficiency). As Orange Poland have embarked on this deployment, a view from Orange Poland and terminals would be welcomed! My perception is that, in this scenario, a number of OS and OEM implementations that can support dual stack perfectly well have not achieved suitability here. For operators who need to decouple their growth from IPv4 addressing, your synopsis of “terminals not blocking rollout” is not the reality. Terminals remain
an issue. But it is not the intention to list problems but to highlight what is required for service continuity. Regards, Nick From: Lorenzo Colitti [mailto:lorenzo@xxxxxxxxxx]
On Tue, Oct 7, 2014 at 8:42 PM, <david.binet@xxxxxxxxxx> wrote:
[DB] Do we consider that all features are mandatory in the draft ? Not at all and it demonstrates
that RFC 2119 terminology is useful. Ok, then. So here are examples of musts that are not required for IPv6 operation in a mobile network, and not supported in widely deployed mobile platforms: C-3 PDP context fallback C-9 RDNSS C-10 DHCPv6 C-11 DNS provisioning order C-12 PDP type limitation W-1 IPv6-only wifi A-1 Privacy addresses (because the IID is provided by the network) A-5 Prefer IPv6 DNS server L-1 DHCPv6 PD L-2 Full Customer Edge Router support A-2 Applications must be IP agnostic A-3 URI format
Then please explain to me how Verizon Wireless supports IPv6 on all its LTE devices, and has done since 2011?
But it does add hurdles for IPv6 deployment. Because it lists lots of requirements that are not required for IPv6 deployment in mobile networks, and that are not widely supported by mobile devices.
Sorry, no. As IETF contributors it is our job to consider what other people will think when they read the documents that we produce. NOTICE AND DISCLAIMER EE Limited |