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

[Lorenzo Colitti <[e-mail]>]

On Tue, Sep 10, 2013 at 8:12 PM, <[e-mail]> wrote:

> *[Med] No. no, no the document indicates the language for each feature:
> there are MUST, SHOULD, etc. This is not the first time a document makes
> such classification of the features.*
>
Sorry - what I meant is: "most of the text in the document says that
devices MUST support this, SHOULD support that, SHOULD support the other",
but not much time saying why.

**
>
> *[Med] There is already motivations text for most of features, rationale
> and scope of the overall effort in the draft. You are continuing ignore it.
> That’s not fair.*
>
Isn't it? For example, look at RFC1122 and compare it to this document.
Compare the percentage of text used to state requirements and the
percentage of text used for rationale. If anything, an informational
document should have fewer requirements and more rationale than a standard,
not the other way around.


> Nobody can control third party-applications, not even the phone
> manufacturer (which is why REQ#33 doesn't make sense).****
>
> *[Med] There are API, there applications shipped by device vendors
> themselves, etc. Our teams already tested applications provided by vendors
> devices which are broken when IPv6-only mode.*
>
Then change the requirement to say vendor applications must not be
IPv4-only. At least it's a reasonable request (though one that's unlikely
to happen before IPv6 is widely deployed). "All apps" is not a reasonable
request.

* *
>
> The manufacturer can provide something like 464xlat, which I agree is
> necessary for IPv6-only operation.
>
> **
>
> *[Med] Are you saying this  is a MUST?*
>
I don't think this document should be a bunch of "MUST this", "SHOULD
that", "MUST the other". As regards 464xlat, I think that shipping an
IPv6-only phone without 464xlat or something equivalent equals shipping a
phone that's not useful, and that doesn't happen in the real world. So if
you want to ship IPv6-only, you need something like 464xlat. Does it follow
that a phone MUST implement 464xlat? No, it does not.


> **
>
> *[Med] How many device support IPv6 today? We can play that game
> endlessly...*
>

Not really, because upwards of 30 million mobile devices are using IPv6
every day on Verizon Wireless alone. See:

http://conference.apnic.net/__data/assets/pdf_file/0017/50813/vzw_apnic_13462152832-2.pdf
http://www.worldipv6launch.org/measurements/

Those phones do not meet the requirements of this draft. They violate at
least MUSTs in #16, #20, #24, #27, #28, plus a large number of SHOULDs.

According to the text in -05, that means they cannot "connect to an
IPv6-only or dual-stack wireless network including 3GPP cellular network
and IEEE 802.11 network)." I know that text won't be there in the next
version, but the point I'm trying to make is that the document made it all
the way to IETF last call while claiming that largest deployment of IPv6 in
a mobile network was not possible. I don't want that to be the message
coming out of this document.

       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 is not about IPv6-only mode.****
>
> *[Med] What is wrong in that text? Can we focus on the exact text change?*
>
"The operators proposing this profile believe that the support of a subset
of the features included in this protocol may lead to degraded level of
service."

 * *
>
> Consider an implementation that implements IPv6 tethering without
> including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD,
> stateful DHCPv6 and all the bells and whistles built in. Or consider a
> 464xlat implementation without a local DNS64 implementation.
>
> **
>
> *[Med] You still do that. These features are not MUST in this document.
> It is your right to ignore them but you need to be aware this may have some
> negative impact. It seems you understand the list as MUST ones…while this
> is not true.*
>
Per the document, if you implement IPv6 tethering you MUST implement a full
RFC 6204 router in the device (req#28).

* *****
>
> ** I don't consider these to be degraded service, I consider them to be a
> lot better than what we have today.
>
> *[Med] I’m sorry to say that a customer with IPv6-only connectivity that
> cannot use some applications available for an IPv4 customer is a degraded
> service. This is seen by some operators as a barrier for that mode.  *****
>
I stand by my opinion that IPv6 tethering without a full RFC6204
implementation and that 464xlat without a local DNS64 implementation are
not degraded.