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

<mohamed.boucadair@orange.com> Fri, 16 November 2012 11:59 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 1842321F852B for <v6ops@ietfa.amsl.com>; Fri, 16 Nov 2012 03:59:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.942
X-Spam-Level:
X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.306, 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 iVixpLaS8WUO for <v6ops@ietfa.amsl.com>; Fri, 16 Nov 2012 03:59:49 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6AB21F8528 for <v6ops@ietf.org>; Fri, 16 Nov 2012 03:59:49 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8CED522CF98; Fri, 16 Nov 2012 12:59:47 +0100 (CET)
Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 67DC4238056; Fri, 16 Nov 2012 12:59:47 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 16 Nov 2012 12:59:46 +0100
From: mohamed.boucadair@orange.com
To: Tore Anderson <tore.anderson@redpill-linpro.com>
Date: Fri, 16 Nov 2012 12:59:45 +0100
Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
Thread-Index: Ac3DQ5sXRF0n9A4RSP6CETaKYS2opQAo1Ijw
Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751E26A@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <50A5064A.1070208@redpill-linpro.com>
In-Reply-To: <50A5064A.1070208@redpill-linpro.com>
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.11.16.63326
Cc: BERNIER Olivier OLNC/OLN <olivier.bernier@orange.com>, 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: Fri, 16 Nov 2012 11:59:50 -0000

Dear Tore,

This is indeed a problem which is encountered with several implementations (both USB dongles and smartphones). My colleague Olivier (cced) reported to me  four implementations are behaving as you described in your message.

This is an implementation issue. We can add a note about these implementation but the recommendation is still: be compliant with REQ#8.

Cheers,
Med

>-----Message d'origine-----
>De : Tore Anderson [mailto:tore.anderson@redpill-linpro.com] 
>Envoyé : jeudi 15 novembre 2012 16:12
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : IPv6 Ops WG
>Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
>
>Hi,
>
>REQ#8 («the cellular host MUST use the interface identifier sent in PDP
>Context Accept message to configure its link local address») is rather
>tricky to implement for a cellular dongle that emulate an Ethernet
>device (such as an USB CDC Ethernet class device). In that case, the
>dongle provides an invented Ethernet MAC address from which the host
>derives an link local address using EUI-64.
>
>Since this link local address does not have the correct interface
>identifier, ND may (partially) break. In particular, I've experienced
>that when sending an RS from such an EUI-64-derived link local address
>to the network, the GGSN reponds with an RA that is unicasted to the
>link local address the network expects the hosts to have. The host has
>no knowledge of this address, and discards the RA.
>
>I don't have a good answer to how this problem should be solved.
>However, if the document could make some recommendations (or at least
>describe the problem), that would be good.
>
>Best regards,
>-- 
>Tore Anderson
>Redpill Linpro AS - http://www.redpill-linpro.com
>