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

Vízdal Aleš <ales.vizdal@t-mobile.cz> Wed, 01 July 2015 13:22 UTC

Return-Path: <ales.vizdal@t-mobile.cz>
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 583F71A8864 for <v6ops@ietfa.amsl.com>; Wed, 1 Jul 2015 06:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.962
X-Spam-Level:
X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2ZsQmyn-kyNj for <v6ops@ietfa.amsl.com>; Wed, 1 Jul 2015 06:22:34 -0700 (PDT)
Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B131A8858 for <v6ops@ietf.org>; Wed, 1 Jul 2015 06:22:33 -0700 (PDT)
From: Vízdal Aleš <ales.vizdal@t-mobile.cz>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "holger.metschulat@telekom.de" <holger.metschulat@telekom.de>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Apple and IPv6, a few clarifications - 64share
Thread-Index: AQHQsm3eGmkYJhNvCEmzMRDqcmE/QJ3GXFmQgAANgoCAADJC8A==
Date: Wed, 01 Jul 2015 13:22:29 +0000
Message-ID: <28c8cdc26b954001aa10a36b9e9baa66@srvhk403.rdm.cz>
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>
In-Reply-To: <5593DAB9.1010202@gmail.com>
Accept-Language: en-GB, cs-CZ, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.254.150.191]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Forwarded
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/W4njYUYp5VIENaAocn5ljEHudng>
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:22:36 -0000

> -----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.

> 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.

> 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.