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

[Alexandru Petrescu <[e-mail]>]

Le 01/07/2015 15:22, Vízdal Aleš a écrit :
>> -----Original Message-----
>> From: Alexandru Petrescu [mailto:[e-mail]]
>> Sent: Wednesday, July 01, 2015 2:19 PM
>> To: Vízdal Aleš; [e-mail]; [e-mail]
>> 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:[e-mail]] On Behalf Of Alexandru Petrescu
>>>> Sent: Monday, June 29, 2015 3:16 PM To:
>>>> [e-mail]; [e-mail] Subject: Re: [v6ops]
>>>> Apple and IPv6, a few clarifications - 64share
>>>>
>>>>
>>>>
>>>> Le 29/06/2015 14:51, [e-mail] 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.
>