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 <lorenzo@google.com> Tue, 10 September 2013 09:27 UTC
Return-Path: <lorenzo@google.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00DE21E80F3 for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2013 02:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-toYJSWgWYw for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2013 02:27:18 -0700 (PDT)
Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 60A1D21E80DC for <ietf@ietf.org>; Tue, 10 Sep 2013 02:27:15 -0700 (PDT)
Received: by mail-qe0-f52.google.com with SMTP id i11so4098803qej.11 for <ietf@ietf.org>; Tue, 10 Sep 2013 02:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=riFD59ZKWJcphaZNJbwuiyevzevti+ZX399AqX668eE=; b=mlInJ8R17PkYUynQ+FTJh9mK+LXdJaQeYYn9Jsdgrehl/hc1eTVrcHikNpIWb5JY00 cXvcyOI53MwVC0ZIgb3MGwQhcgK2F84F7QULdyy4t9hBN5t3A8C8WiFTsL+FeRV+BoZP sPThu6ppibyT9/zTaZff2Ql4ouIQtO+r/FfSzMCWUwg8CQSiYSxgRrPeuvcGPUTmJxlC MOWJTjq20VMH92O5Dfq3yEab6CHMgwY06N81GEKUYfEoG+QqhT0CNN4acMOwvYMspczS RoRaeJ1poyq/30BS18JOrjna3PJbZJT+jyITpMTvrOHexpfJhM/LJgASU3bV3htFDfD9 z3EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=riFD59ZKWJcphaZNJbwuiyevzevti+ZX399AqX668eE=; b=fguLMD/uvvgHsbmotgmC5iZ41KvkviU3z5e17iRjG5U9sDI1krdeCM3aooh5AaDKMm ZYukXSgQgOFp4AkDnSYHEnqOToyI9Hm6gijvyV/Gx9EPZEcN7grjjtd8m5c2Baco/6Um encimp290j+37NP99t+PKt7mUwSsggVBqPwDs0IcGbGn6lc44mTjsgVfht7bYgPDwR6P oDgpFtjCrd9hGDphLTbkImHLMpmq8F6c6uACeEdChxgo76lexVPfnttg9enWXYI515X7 U9y+MjJjZJ/PCjd7VYk50kPrCNVSwuYIhsf18xxh+G9H7of13K/cK4wPL+PZ+PnWXkJP /HjQ==
X-Gm-Message-State: ALoCoQlVPMKrH1PU74QJNGlV4s9ugGrh7OIS/KsS7j+kx0K+miRMTzaYggXGTGOUQOGw41xIEfLe3BsRKOgfCFAFAVH/G8epg0E82hnPIsFnQ1Dhyox365czoMlx1ulskIamvAjHlekypmhwpUsYFY2IYW43cTLXGwYYD8CF13M+Fay+8wv3Knp0mKvP83XsR0I4dj259Wv3
X-Received: by 10.49.127.116 with SMTP id nf20mr1216992qeb.90.1378805234664; Tue, 10 Sep 2013 02:27:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.47.137 with HTTP; Tue, 10 Sep 2013 02:26:53 -0700 (PDT)
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr>
References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <CAKD1Yr1VpJne1h-Q5xbNMYRhpr_n0Wmn6UqfeG3vEg2MY6ms1g@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr0pqeO9KdcKFWVqWP_5pmZ6fgQ5h4tQ=vOO57d-dg5+DA@mail.gmail.com> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <CAKD1Yr3SddZio-vHGHK=5smb94HP58cY05_TGgWQpkS3=Ay8_w@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr0CUzSDv9H1eCUpMRUjBDS2OCkfsfE+S+3J8Z-_6=uVSg@mail.gmail.com> <CAKHUCzwYrjyobah-oPWD3vwUeUH5XZ7U=Fqof-f28tneS8jAvQ@mail.gmail.com> <CAKD1Yr0_yOaDjrH-5K696YaziZZR+EMxdRCf=JZBW5LZgWS45Q@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr3cgJ-xumsMK3eL3zySGsPqXU9uw4L857bJ0VEGcA5mBQ@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr2WgEi7vg3K9yFgmG64jduZN0kDD5o0m0f1Lfy=dZ28Zw@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr37HR=nTauzTMri3ss4DJt3OawK0vDvWgXqxMwsY3xgww@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 10 Sep 2013 18:26:53 +0900
Message-ID: <CAKD1Yr2+hT+27J1VnENrgPABUcRSka-MeQKwNQgGAdhWvuFQpg@mail.gmail.com>
Subject: 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
To: "<mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com>
Content-Type: multipart/alternative; boundary="047d7b5d8d5f3a478004e6041c53"
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, IETF Discussion <ietf@ietf.org>, BINET David IMT/OLN <david.binet@orange.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2013 09:27:19 -0000
On Tue, Sep 10, 2013 at 5:18 PM, <mohamed.boucadair@orange.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. 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, without saying why, and without giving any information to operators, implementers, or anyone else on why this particular laundry list of features was selected. That's not a good way to specify things. Look at RFC1122, for example: every requirement is carefully articulated, with rationale and everything else. > 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). The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation. > 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? > 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. 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. I don't consider these to be degraded service, I consider them to be a lot better than what we have today. But someone taking this document as a guide to what needs to be implemented to deploy IPv6 would consider them to be incomplete or broken implementations. Such a person might look at the 34 requirements and just give up, when in fact such an implementation is perfectly capable of doing IPv6 today.
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… james woodyatt
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Owen DeLong
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Erik Kline
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: Last Call: <draft-ietf-v6ops-mobile-device-pr… Abdussalam Baryun
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… david.binet
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Gert Doering
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… SM
- Re: Re: [v6ops] Last Call: <draft-ietf-v6ops-mobi… Ray Hunter
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Dave Cridland
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Hannes Tschofenig
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Ted Lemon
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Ted Lemon
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… joel jaeggli
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- RE: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Mark ZZZ Smith
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Owen DeLong
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Owen DeLong
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… joel jaeggli
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Abdussalam Baryun
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… joel jaeggli
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… joel jaeggli
- Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-d… Owen DeLong