Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

<mohamed.boucadair@orange.com> Thu, 19 February 2015 12:13 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A0F1A8ADB for <v6ops@ietfa.amsl.com>; Thu, 19 Feb 2015 04:13:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level:
X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BiyoNsUVwA8 for <v6ops@ietfa.amsl.com>; Thu, 19 Feb 2015 04:13:29 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C057C1A87D5 for <v6ops@ietf.org>; Thu, 19 Feb 2015 04:13:28 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id CB0343B413C; Thu, 19 Feb 2015 13:13:26 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id AA1DB27C0B2; Thu, 19 Feb 2015 13:13:26 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Thu, 19 Feb 2015 13:13:21 +0100
From: <mohamed.boucadair@orange.com>
To: Lorenzo Colitti <lorenzo@google.com>, BINET David IMT/OLN <david.binet@orange.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
Thread-Index: AQHQTC9pixBJZ1L350WogIuKXDMPO5z33+Tw
Date: Thu, 19 Feb 2015 12:13:21 +0000
Message-ID: <fdc7ab8c-4f63-43eb-a77b-4764f24d9486@OPEXCLILH01.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAKD1Yr2yDnwPDHgsq3Wi3UOzKY7KrqSpBMbBttJ5qAAu6ijOAw@mail.gmail.com> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr0j23E-UMdL2Ujv5nrpbbUa9rgPE_6AhbHLn0JeOZ9Edg@mail.gmail.com> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <CAKD1Yr2PX81czTwUZzaMtgPc9vhvP=oL++UZByGzxmkq_B=DMA@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr0Zkic6-ydV-u==xjDGdY9GYWb8KwciBPnfk8zO=6FFqQ@mail.gmail.com> <CAKD1Yr0qS-Vg-XB7mNWwephkkL5rCG+NJO7uDJg_4W3LT+Q9Ew@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr00Ri8hQMsJcSqMAw+g_T-mU8GxG1G8rTHgo=McaKdW8Q@mail.gmail.com> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAKD1Yr2+BMSifTS3x0WD5LqKYe-Yse8CGf4Egaijp=8DVSf5UA@mail.gmail.com>
In-Reply-To: <CAKD1Yr2+BMSifTS3x0WD5LqKYe-Yse8CGf4Egaijp=8DVSf5UA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: multipart/alternative; boundary="_000_fdc7ab8c4f6343eba77b4764f24d9486OPEXCLILH01corporateadr_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.19.110025
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/LY0Pons1MKGyyjlhgzWIOdWUK-M>
Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 12:13:33 -0000

Hi Lorenzo,

Please see inline.

Cheers,
Med

De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Lorenzo Colitti
Envoyé : jeudi 19 février 2015 11:33
À : BINET David IMT/OLN
Cc : IPv6 Ops WG (v6ops@ietf.org)
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 1:39 AM, <david.binet@orange.com<mailto:david.binet@orange.com>> wrote:

[DB] Could you be more explicit and indicate which features are not useful in the draft ? As you can mention it, all features are not indicated as mandatory in the draft so I do not clearly understand how this document conflicts with what you say considering that the goal for the operator is to provide at least the same service access for users with IPv6 connectivity than for users with IPv4 connectivity whatever the strategy retained by the operator.

If the goal of the document is "to provide at least the same service access for users with IPv6 connectivity than for users with IPv4 connectivity whatever the strategy retained by the operator"

[Med] This is one of the goals of the I-D not the only one. e.g., the I-D lists features that are not covered in RFC7066 and RFC6434: e.g., prefix delegation or prefix sharing.

then you can reduce the document to two requirements:

[Med] I’m afraid compacting the recommendations is not helpful. For example, these two items are covered as follows in the I-D for the sake of deterministic behavior.

1. Support both IPv4v6 and IPv6.

[Med] These items cover this 1st point:

   C_REC#1:  In order to allow each operator to select their own
             strategy regarding IPv6 introduction, the cellular host
             must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.23060>]0>].
             IPv4, IPv6 or IPv4v6 PDP-Context request acceptance depends
             on the cellular network configuration.

   C_REC#2:  The cellular host must comply with the behavior defined in
             [TS.23060<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.23060>] [TS.23401<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.23401>] [TS.24008<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.24008>] for requesting a PDP-
             Context type.  In particular, the cellular host must
             request by default an IPv6 PDP-Context if the cellular host
             is IPv6-only and request an IPv4v6 PDP-Context if the
             cellular host is dual-stack or when the cellular host is
             not aware of connectivity types requested by devices
             connected to it (e.g., cellular host with LAN capabilities
             as discussed in Section 3<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#section-3>)3>):

             *  If the requested IPv4v6 PDP-Context is not supported by
                the network, but IPv4 and IPv6 PDP types are allowed,
                then the cellular host will be configured with an IPv4
                address or an IPv6 prefix by the network.  It must
                initiate another PDP-Context activation in addition to
                the one already activated for a given APN (Access Point
                Name).

             *  If the subscription data or network configuration allows
                only one IP address family (IPv4 or IPv6), the cellular
                host must not request a second PDP-Context to the same
                APN for the other IP address family.

             The text above focuses on the specification part which
             explains the behavior for requesting IPv6-related PDP-
             Context(s).  Understanding this behavior is important to
             avoid having broken IPv6 implementations in cellular
             devices.


   C_REC#3:  The cellular host must support the PCO (Protocol
             Configuration Options) [TS.24008<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.24008>] to retrieve the IPv6
             address(es) of the Recursive DNS server(s).

                In-band signaling is a convenient method to inform the
                cellular host about various services, including DNS
                server information.  It does not require any specific
                protocol to be supported and it is already deployed in
                IPv4 cellular networks to convey such DNS information.

   C_REC#4:  The cellular host must support IPv6 aware Traffic Flow
             Templates (TFT) [TS.24008<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.24008>]8>].

                Traffic Flow Templates are employing a packet filter to
                couple an IP traffic with a PDP-Context.  Thus a
                dedicated PDP-Context and radio resources can be
                provided by the cellular network for certain IP traffic.


2. Support 464xlat.
[Med] “464xlat” is meaningless for the device;-) but I got your point. This is covered by the following two items:


   C_REC#8:  In order to ensure IPv4 service continuity in an IPv6-only

             deployment context, the cellular host should support a

             method to locally construct IPv4-embedded IPv6 addresses

             [RFC6052<http://tools.ietf.org/html/rfc6052>]2>].  A method to learn PREFIX64 should be supported

             by the cellular host.



                This solves the issue when applications use IPv4

                referrals on IPv6-only access networks.



                In PCP-based environments, cellular hosts should follow

                [RFC7225<http://tools.ietf.org/html/rfc7225>] to learn the IPv6 Prefix used by an upstream

                PCP-controlled NAT64 device.  If PCP is not enabled, the

                cellular host should implement the method specified in

                [RFC7050<http://tools.ietf.org/html/rfc7050>] to retrieve the PREFIX64.



   C_REC#9:  In order to ensure IPv4 service continuity in an IPv6-only

             deployment context, the cellular host should implement the

             Customer Side Translator (CLAT, [RFC6877<http://tools.ietf.org/html/rfc6877>]) function in

             compliance with [RFC6052<http://tools.ietf.org/html/rfc6052>][RFC6145][RFC6146<http://tools.ietf.org/html/rfc6146>]rfc6146>].



                CLAT function in the cellular host allows for IPv4-only

                application and IPv4-referals to work on an IPv6-only

                connectivity.  The more applications are address family

                independent, the less CLAT function is solicited.  CLAT

                function requires a NAT64 capability [RFC6146<http://tools.ietf.org/html/rfc6146>] in the

                network.



                The cellular host should only invoke the CLAT in the

                absence of the IPv4 connectivity on the cellular side,

                i.e., when the network does not assign an IPv4 address

                on the cellular interface.  Note, NAT64 assumes an

                IPv6-only mode [RFC6146<http://tools.ietf.org/html/rfc6146>]6>].



                The IPv4 Service Continuity Prefix used by CLAT is

                defined in [RFC7335<http://tools.ietf.org/html/rfc7335>]5>].



                CLAT and/or NAT64 do not interfere with native IPv6

                communications.