Re-,
Please see inline.
Cheers,
Med
De : Lorenzo Colitti [mailto:lorenzo(_at_)google(_dot_)com]
Envoyé : mardi 10 septembre 2013 11:27
À : BOUCADAIR Mohamed IMT/OLN
Cc : Dave Cridland; v6ops(_at_)ietf(_dot_)org 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 5:18 PM,
<mohamed(_dot_)boucadair(_at_)orange(_dot_)com<mailto:mohamed(_dot_)boucadair(_at_)orange(_dot_)com>>
wrote:
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 need to support IPV4V6 if all you need to do is work on an IPv6-only
network.
[Med] UEs that will provided with IPv6-only or DS is up to the provider. Note
also that the requirement is worded to let the decision to each provider. The
document explicitly says:
This allows each operator to select their own strategy
regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP-
Contexts MUST be supported. IPv4, IPv6 or IPv4v6 PDP-Context
request acceptance depends on the cellular network
configuration.
That might seem like a stupid answer, but the point I'm trying to make is that
while you and I know that supporting only IPV6 will result in the phone being
incompatible with some networks *the document doesn't say that*. The document
says you MUST support all this stuff
[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.
, without saying why, and without giving any information to operators,
implementers, or anyone else on why this particular laundry list of features
was selected.
[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.
That's not a good way to specify things. Look at RFC1122, for example: every
requirement is carefully articulated, with rationale and everything else.
[Med] This document is not a standard. This document does not ambition to have
the same level as RFC1122.
you don't have a means to make work broken applications when IPv6-only is
enabled
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.
The manufacturer can provide something like 464xlat, which I agree is necessary
for IPv6-only operation.
[Med] Are you saying this is a MUST?
if the phone does not follow the procedure for requesting the PDP context,
You don't need to do that if you have an APN database that's configured with
what the operator supports, or if you don't support IPV4V6. (Straying back into
technical discussion for a bit - from a technical point of view, having seen
the wide variety of behaviours and result codes that basebands typically
exhibit when you ask them to do something that they or the network doesn't
support, I think relying on this fallback is a terrible idea.)
how you can be compatible with DNSSEC, etc.
How many phones today support DNSSEC?
[Med] How many device support IPv6 today? We can play that game endlessly...
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?
That's a useful feature, and as I'm sure you know, it's been implemented by a
number of manufacturers.
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.
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.