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

[Owen DeLong <[e-mail]>]

Perhaps I'm still confused or truly don't understand all of the IP-specific implications of 3g/4g/other cellular protocols.

However, it seems to me that from an IETF perspective, the various interfaces on a cell phone (802.11, 3gpp, LTE, etc.) are just various layer 2 media. The phone itself is just another host and/or router.

Most of what is contained in this document strikes me as an effort to shift the work in media adaptation out of the media standards bodies and into the IETF solely because the cellular standards bodies, vendors, et. al. don't seem to be able to come together and build reasonable working documents.

Unfortunately, the result is an I-D/RFC that is slightly less complicated than the Bluetooth specification and nearly as legible.

PDP contexts are a media adaptation problem unique to the (bizarre) choices of the cellular industry in order to support their arcane billing and licensing schemes.

Every other media, it has been left to the media standards group to develop the necessary media adaptation layers for IP. This document seems to be trying to shift that role into the IETF for this particular implementation of a combination of media types, some of which already have adaptation layers specified in their respective standards group, some of which may not, and many of which are made unusually complex and twisted by the unique nature of the accounting systems that are involved.

I haven't seen an IETF profile document for Ethernet, Token Ring, PPP, HDLC, FDDI, Firewire, USB, ATM, etc.

The requirements documents for hosts and routers are already in reasonably good shape. Efforts are already underway to update them with operational experience and more recent lessons learned.

It is my opinion that this document will, in the long run, merely create additional confusion as it is likely to conflict with future output from 3GPP and other standards bodies responsible for the media that is unique to the cellular world and overlaps and may also conflict with documents from IEEE and other standards bodies that control some of the other network interfaces currently present on cellular devices and/or likely to be present in the future (such as BLE and 802.16).

Yes, the 3GPP standards are currently rather lacking in their IP adaptation guidance and the cellular industry is a quagmire of competing interests and malformed overly-political standards processes. I do not believe that bringing that into the IETF will do anything to reduce the quagmire in the cellular industry, nor will it do anything to benefit IPv6 or IPv6 deployment.

Owen

On Sep 10, 2013, at 01:18 , [e-mail] wrote:

> Re-,
>  
> I really don’t see how you can have a phone that “make a phone that works perfectly well on an IPv6-only” if you don’t support IPv6/IPv4v6 PDP context, you don’t have a means to make work broken applications when IPv6-only is enabled, if the phone does not follow the procedure for requesting the PDP context, how you can be compatible with DNSSEC, etc. 
>  
> If what you mean by “perfect” is a degraded level of service, then you are right. 
>  
> I update the text to reflect this:
>  
>       NOTE WELL: This document is not a standard, and conformance with
>       it is not required in order to claim conformance with IETF
>       standards for IPv6.  The support of the full set of features may
>       not be required in some contexts (e.g. dual-stack).  The support
>       of a subset of the features included in this profile may lead to
>       degraded level of service (e.g., IPv6-only mode).
>  
>       This document uses the normative keywords defined in the previous
>       section only for precision.
>  
> Is this better?
>  
> Cheers,
> Med
>  
> De : Lorenzo Colitti [mailto:[e-mail]] 
> Envoyé : mardi 10 septembre 2013 09:21
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Dave Cridland; [e-mail] WG; BINET David IMT/OLN; IETF Discussion
> Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
>  
> On Tue, Sep 10, 2013 at 3:57 PM, <[e-mail]> wrote:
> I have considered that Lorenzo. “is not required to deploy IPv6” would be accurate if this document is dealing only with dual-stack, but this is not true for the IPv6-only mode. The set of SHOULD recommendations are targeting that deployment model.
>  
> I disagree. By my reading, you can make a phone that works perfectly well on an IPv6-only carrier network without implementing #2, #3, #9, #10, #11, #12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. Some of those are MUSTs in this document.
>  
> If you want to do IPv6-only on wifi you need either #9 and #10 (or both plus #11 as well), and either #20 or #21 (or both plus #23). But the other ones are not necessary to deploy an IPv6-only phone. One of your co-authors will be able to confirm this: I'm told there are multiple IPv6-only phones on T-Mobile USA today, and I'm sure none of them implement all the requirements in this document (or even all the MUSTs).
>  
>  
> [*] How did #18 even make it in? What use is a MAY in a requirements document? Of course implementors MAY do anything they want, unless they SHOULD NOT or MUST NOT.
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops