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

From: Vízdal Aleš <[email-masked]>
Date: Wed, 1 Jul 2015 09:35:09 +0000

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandru
> Petrescu
> Sent: Monday, June 29, 2015 3:16 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share
>
>
>
> Le 29/06/2015 14:51, [email-masked] 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. The DHCPv6 server
could be run by the dongle and providing that RA provided prefix via DHCPv6
to the host.

> I guess that hardware which blocks DHCPv6-PD also blocks DHCPv6.
> Otherwise it would be an intentional blocking of DHCPv6-PD...
>
> 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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 1 Jul 2015 14:19:05 +0200

Le 01/07/2015 11:35, Vízdal Aleš a écrit :
>> -----Original Message----- From: v6ops
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Monday, June 29, 2015 3:16 PM To:
>> [email-masked]; [email-masked] Subject: Re: [v6ops]
>> Apple and IPv6, a few clarifications - 64share
>>
>>
>>
>> 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.

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)

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

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

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 1 Jul 2015 13:22:29 +0000

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Wednesday, July 01, 2015 2:19 PM
> To: Vízdal Aleš; [email-masked]; [email-masked]
> >> address.  But if I make a DHCPv6 Prefix Delegation request then that
> >> is not answered.
> >
> 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.

> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 1 Jul 2015 15:35:27 +0200

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

> 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

---

From: Ross Chandler <[email-masked]>
Date: Mon, 13 Jul 2015 08:24:43 +0100

Hi David,

Could you look at supporting this common handset/hotspot APN case with IPv6 & IPv4 APN protocol on two separate bearers with the latter only brought up when hotspot is on. 

Like Nick indicates there are unpalatable business implications that effectively block iOS deployment with IPv6-only. Until the business starts asking for IPv6 we need ways of making the transition that are minimally disruptive. 

Ross

> On 2 Jul 2015, at 08:40, Heatley, Nick <[email-masked]> wrote:
> 
> I don't know what a mobile operator with a common Internet APN strategy can do about tethering/hotspot then?
> Other than redefining all the business logic that leads to a common Internet APN.
> 
> (I hope you agree, the ability to services all device types on the wifi is mandatory - even iOS customers might have laptops of various OS in their home or business.)
> Nick
> 
> 
> From: David Schinazi [mailto:[email-masked]] 
> Sent: 01 July 2015 23:29
> To: Heatley, Nick
> Cc: Ross Chandler; Vividh Siddha
> Subject: Re: [v6ops] Apple and IPv6, a few clarifications
> 
> Nick, Ross,
> 
> Sorry about the delay.
> 
> As far as I know, this is not currently supported:
> 
>> Does/could iOS allow this?
>> 
>> Handset APN name = Hotspot APN name
>> 
>> but with
>> 
>> Handset APN protocol = IPv6-only  & Hotspot APN protocol = IPv4-only
> 
> 
> David

---

From: "Heatley, Nick" <[email-masked]>
Date: Mon, 13 Jul 2015 07:40:51 +0000

Agree. Each market must make tariffing decisions independent of IP protocol choice.

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Ross Chandler
Sent: 13 July 2015 08:25
To: IPv6 Ops WG; David Schinazi
Cc: Vividh Siddha
Subject: Re: [v6ops] Apple and IPv6, a few clarifications

Hi David,

Ross

> (I hope you agree, the ability to services all device types on the 
> wifi is mandatory - even iOS customers might have laptops of various 
> OS in their home or business.) Nick
> 
> 

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Jul 2015 15:04:32 +0200

On 22 Jun 2015, at 16:33, Iljitsch van Beijnum <[email-masked]> wrote:

> About the test DNS64/NAT64 implementation:

> Obviously the test network isn't a "real" NAT64 test network when there's no native IPv6 present. And obviously there's no easy way to have native IPv6 materialize out of thin air. But someone who wants to test more thoroughly may want to get native IPv6 or set up a tunnel broker tunnel. It would be nice if the test NAT64 setup could work with that, so the devices on the test network can connect to IPv6 destinations over IPv6 and IPv4 destinations through the NAT64.

> Basically, what's needed for this is that if the interface in question is configured with "real" IPv6 addresses, those are kept and the prefix in question is advertised in RAs.

See here for a workaround, although I can't seem to figure out these disappearing default routes:

http://www.muada.com/2015/07-13-taking-apples-nat64-implementation-for-a-spin.html