IETF Logo Mail Archive

Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

<mohamed.boucadair@orange.com> Mon, 12 November 2012 10:17 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6B821F8488 for <v6ops@ietfa.amsl.com>; Mon, 12 Nov 2012 02:17:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.759
X-Spam-Level:
X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Fwm-oNqpUwA for <v6ops@ietfa.amsl.com>; Mon, 12 Nov 2012 02:17:58 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0323821F844D for <v6ops@ietf.org>; Mon, 12 Nov 2012 02:17:58 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 33EF23B41FE; Mon, 12 Nov 2012 11:17:57 +0100 (CET)
Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 12AF527C046; Mon, 12 Nov 2012 11:17:57 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 12 Nov 2012 11:17:56 +0100
From: mohamed.boucadair@orange.com
To: Mikael Abrahamsson <swmike@swm.pp.se>
Date: Mon, 12 Nov 2012 11:17:55 +0100
Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
Thread-Index: Ac3Au2hesLopbpKjR+aCD9kd/MPnHQAAK/Dg
Message-ID: <94C682931C08B048B7A8645303FDC9F36E947B14B5@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <alpine.DEB.2.00.1211120839240.27834@uplift.swm.pp.se> <94C682931C08B048B7A8645303FDC9F36E947B1427@PUEXCB1B.nanterre.francetelecom.fr> <alpine.DEB.2.00.1211121043220.27834@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.00.1211121043220.27834@uplift.swm.pp.se>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 12 Nov 2012 10:17:59 -0000

Re-,

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : Mikael Abrahamsson [mailto:swmike@swm.pp.se] 
>Envoyé : lundi 12 novembre 2012 10:52
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : IPv6 Ops WG
>Objet : RE: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
>
>On Mon, 12 Nov 2012, mohamed.boucadair@orange.com wrote:
>
>> Med: We wanted to focus on the specification part which 
>describes the 
>> behaviour for requesting IPv6-related PDP context(s). This 
>is important 
>> to avoid having broken IPv6 implementations in cellular devices.
>
>Perhaps text could be included in the document about this, 
>it's included 
>for some other requirements.

Med: I added this to my local copy:

        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.

Do we need to say more?

>
>>> REQ#10: Why shouldn't the host support DHCPv6 recursive DNS
>>> retreival if
>>> RFC6106 is supported?
>>
>> Med: This is not what the req says. The req says:
>>
>>   REQ#10:  The cellular host SHOULD embed a DHCPv6 client [RFC3736].
>>
>> DHCPv6 gives more information than
>>> RFC6106, I think
>>> the device should support DHCPv6 regardless of RFC6106 support.
>>
>> Med: The sub-requirements is only about the DNS information.
>
>Perhaps this could be clarified?

Med: I updated the text as follows:

OLD:

             If [RFC6106] is not supported, the cellular host SHOULD
             retrieve DNS information using stateless DHCPv6 [RFC3736].

NEW:

             If [RFC6106] is not supported, the cellular host SHOULD
             retrieve DNS information using stateless DHCPv6 [RFC3736].
             Note stateless DHCPv6 is useful to retrieve other
             information than DNS.

>
>>> REQ#15: Is the rationale here that a device with IPv4v6 PDP
>>> context will
>>> get a DNS64 enabled resolver?
>>
>> Med: No. The point is the host has to enforce a procedure to 
>prefer native IPv6 connectivity.
>
>I think REQ#15 should be re-written.
>
>REQ#15: The cellular host SHOULD, when dual stacked, support means to 
>prefer native IPv6 connection when faced with possibility of 
>native IPv6, 
>NAT64 or NAT44 connection to the same destination.
>
>... or something to that effect. The find the current wording 
>confusing.

Med: I updated the text as follows:

OLD:

   REQ#15:  The cellular host SHOULD support means to prefer native IPv6
        connection over NAT64 devices or NAT44 when the cellular host
        gets dual stack connectivity.

NEW:

   REQ#15:  When the cellular host is dual stack connected, it SHOULD
        support means to prefer native IPv6 connection over NAT64
        devices or NAT44.

Better?

>
>>> REQ#17: Should not do DAD on the PDP context interface. In case of
>>> tethering/hotspot, it needs to do DAD on the wifi/lan 
>interface, right?
>>
>> Med: Yes.
>
>Clarification in the text?

Med: I updated the text as follows:

OLD:

   REQ#17:  The cellular host SHOULD NOT perform Duplicate Address
        Detection (DAD) for these Global IPv6 addresses (as the GGSN or
        PDN-GW must not configure any IPv6 addresses using the prefix
        allocated to the cellular host).

NEW:

   REQ#17:  The cellular host SHOULD NOT perform Duplicate Address
        Detection (DAD) for these Global IPv6 addresses (as the GGSN or
        PDN-GW must not configure any IPv6 addresses using the prefix
        allocated to the cellular host).  Refer to Section 4 for DAD
        considerations on the LAN interface when the 3GPP connection is
        shared.

Are you Ok with the new text?

v2.23.0 | Report a Bug | By Email