Re: [v6ops] Apple and IPv6, a few clarifications - 64share

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 01 July 2015 13:35 UTC

Return-Path: <alexandru.petrescu@gmail.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 36CBD1A88DC for <v6ops@ietfa.amsl.com>; Wed, 1 Jul 2015 06:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.683
X-Spam-Level:
X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 QQbUYmiHqcIo for <v6ops@ietfa.amsl.com>; Wed, 1 Jul 2015 06:35:32 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89EF1A88C0 for <v6ops@ietf.org>; Wed, 1 Jul 2015 06:35:31 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t61DZTCB000573; Wed, 1 Jul 2015 15:35:29 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1F980205223; Wed, 1 Jul 2015 15:38:36 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 11F2B205222; Wed, 1 Jul 2015 15:38:36 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t61DZRH7018146; Wed, 1 Jul 2015 15:35:29 +0200
To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= <ales.vizdal@t-mobile.cz>, "holger.metschulat@telekom.de" <holger.metschulat@telekom.de>, "v6ops@ietf.org" <v6ops@ietf.org>
References: <E1C235B5-1421-4DAF-A2F3-F963982233DF@apple.com> <5587EFDD.6030807@gmail.com> <alpine.DEB.2.02.1506221415100.9487@uplift.swm.pp.se> <CAAedzxo7Cqxwrp_zViDhOhWc+dtcy9M9=a-FjW7M8APNx7VUQA@mail.gmail.com> <CAD6AjGTscUeDL6zC62tHL300M9QCD4_CHZUErQYejMUJVVetzw@mail.gmail.com> <558AA4F1.8080503@gmail.com> <88CAA5385EB5404392BF93106C8C53F89620073E87@HE111507.emea1.cds.t-internal.com> <55914517.4050602@gmail.com> <ea33d5cbd7b340179a839eec242240e4@srvhk403.rdm.cz> <5593DAB9.1010202@gmail.com> <28c8cdc26b954001aa10a36b9e9baa66@srvhk403.rdm.cz>
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Message-ID: <5593EC9F.6060700@gmail.com>
Date: Wed, 1 Jul 2015 15:35:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <28c8cdc26b954001aa10a36b9e9baa66@srvhk403.rdm.cz>
Content-Type: text/plain; charset=iso-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/mP0VOIrXMsia0Zv2pD69Xv9PPu8>
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 01 Jul 2015 13:35:35 -0000


Le 01/07/2015 15:22, Vízdal Aleš a écrit :
>> -----Original Message-----
>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
>> Sent: Wednesday, July 01, 2015 2:19 PM
>> To: Vízdal Aleš; holger.metschulat@telekom.de; v6ops@ietf.org
>> Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share
>>
>>
>>
>> Le 01/07/2015 11:35, Vízdal Aleš a écrit :
>>>> -----Original Message----- From: v6ops
>>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu
>>>> Sent: Monday, June 29, 2015 3:16 PM To:
>>>> holger.metschulat@telekom.de; v6ops@ietf.org Subject: Re: [v6ops]
>>>> Apple and IPv6, a few clarifications - 64share
>>>>
>>>>
>>>>
>>>> Le 29/06/2015 14:51, holger.metschulat@telekom.de a écrit :
>>>
>>>> The modem and chipsets on LTE that I have tried do forward DHCPv6
>>>> requests.  For example it transmits the DHCPv6 Request and then
>>>> receives an DHCPv6 Ack from the cellular network containing an IPv6
>>>> address.  But if I make a DHCPv6 Prefix Delegation request then that
>>>> is not answered.
>>>
>>> The current 3GPP specs do not contain DHCPv6 based IPv6 prefix
>>> allocation, so I would be surprised by an LTE network doing so.
>>
>> 'Prefix Allocation' or Prefix Delegation?   Because Section 5.3.1.2.6.
>> or this 3GPP/ETSI spec does tell DHCPv6 Prefix Delegation, between the LTE
>> network and the UE.
>
> Initial Prefix Allocation (/64), I am not talking about PD.

Ok.  My interest is in DHCPv6 PD to UE, and waiting for it to come up in 
the operator network.

I agree there is also DHCPv6-PD in the core of LTE between various 
entities of the LTE network, and further deep in the Internet.  That is 
also specified and implemented in some deployments.

But I do not know what more precisely is meant by Prefix Allocation - 
who allocates to whom, and by what protocol.

>> http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/10.03.00_60/ts
>> _123401v100300p.pdf
>>
>> http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/12.06.00_60/ts
>> _123401v120600p.pdf
>>
>> (in this way one can see the history of it).
>>
>>> The DHCPv6 server could be run by the dongle and providing that RA
>>> provided prefix via DHCPv6 to the host.
>>
>> If that is a question, the answer is no, the DHCPv6 server is not running by the
>> dongle, because the IP address provided by DHCP is different than the IP
>> address formed from the RA: both the prefix and the IID.
>>
>> The DNS server provided by RA is different than the DNS server provided by
>> DHCP.  The DNS server provided by DHCP works fine whereas the one provided
>> by RA does not work.  (So I end up with a situation where I must use both
>> DHCP and RA, which is a burden)
>
> It looks that the dongle is acting as a router then.

No, I do not understand why would one think so. I have the feeling the
LTE dongle is not even a bridge. It's more like a modem connected by a
serial line to the computer. It has a single MAC address printed on it
(not 2 as a router would), sysadmin uses qmicli or mmcli with parameters
such as USB driver name to control it (not ssh or SNMP involving IP
addresses), etc. Why do you think the USB dongle is a router?

Alex

>
>> After having queried the operator in question I continue to think DHCPv6-PD is
>> not provided by the network, although DHCPv6 for addresses _is_.
>>
>> Alex
>
> Ales
>
>
> Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer.
>