Subject: [v6ops] Apple and IPv6, a few clarifications

From: David Schinazi <[email-masked]>
Date: Fri, 19 Jun 2015 14:46:36 -0700

Hi everyone,

I'd like to clarify a few points about Apple's IPv6 announcements during WWDC 2015.
The video (streaming with Safari or download with all browsers) and slides of that talk
are available at: https://developer.apple.com/videos/wwdc/2015/?id=719 <https://developer.apple.com/videos/wwdc/2015/?id=719>

*) Personal hotspot on iOS
If your iPhone has dual-stack connectivity on its cellular network, the hotspot it creates
will be dual-stack as well. The phone will share its prefix with Wi-Fi clients.

*) Internet Sharing on the Mac
Today, regular internet sharing (from your ethernet to Wi-Fi for example) does not
support IPv6 because of the limited use cases, and the lack of demand for it.

*) Internet Sharing on the Mac - NAT64 testing mode
The NAT64 test mode was designed to help developers ensure that their app can still
function with IPv6-only NAT64+DNS64 connectivity and communicate with their IPv4
server, even if the developer does not have access to the IPv6 internet. That NAT64
network does not have IPv6 connectivity to the global IPv6 internet. As such, the current
version advertises addresses from 2001::/64 instead of ULAs to simulate real IPv6
connectivity, as all IPv6 packets are terminated at the NAT64 server on the Mac.
This implementation detail could change in the future.

*) Making IPv4 literals work on NAT64 networks when using high-level APIs
Starting with this year's versions, if you use NSURLSession to connect to an IPv4
literal on an IPv6-only NAT64-DNS64 network, the API will bump in a IPv6 literal
synthesized using RFC 7050. Note that this will not happen when using sockets
directly. We do not support under-the-sockets bump-in-API (RFC 3338) and we
do not support 464XLAT.

*) Happy Eyeballs
We've heard feedback on our Happy Eyeballs implementation and are investigating
this topic.

Note that this reflects how these technologies work in the current versions of the
2015 betas, many of these details could change in future betas. Please keep in mind
that these betas are previews and we welcome feedback on improving them.

Feel free to contact me if you have any questions, I will also attend IETF93.

Thanks,
David Schinazi
Apple CoreOS Networking Engineer

---

From: Ca By <[email-masked]>
Date: Fri, 19 Jun 2015 15:10:16 -0700

David,

All of this is good news.  Thank you.

I assume the goal is for Apple users to have a good experience on
production ipv6-only nat64/dns64 network.

When do you expect mobile operators to be able to launch production quality
ipv6-only? When should the apn config flip from ipv4 to ipv6?

Finally, are you running your iPhone on ipv6-only LTE?  I am. It is very
important to eat the dog food.

CB

On Friday, June 19, 2015, David Schinazi <[email-masked]> wrote:

> are available at: https://developer.apple.com/videos/wwdc/2015/?id=719
>

---

From: Tore Anderson <[email-masked]>
Date: Sat, 20 Jun 2015 11:21:30 +0200

Hello David,

First of all, let me say that the news from WWDC is very exciting, and
I hope your strategy proves successful. With some luck, your approach
of forcing app developers to write IPv6-capable code will also
indirectly benefit the other platforms too.

I have some follow-up questions though, see in-line:

* David Schinazi

> If your iPhone has dual-stack connectivity on its cellular network,
> the hotspot it creates will be dual-stack as well. The phone will
> share its prefix with Wi-Fi clients.

And if the cellular network is IPv6-only? Does the tethered WLAN become
IPv6-only too? If so, I can imagine that this would cause IPv4
compatibility issues for older Apple devices without the new
Bump-in-the-API stuff, as well as for non-Apple devices attaching to
the tethered WLAN.

Hopefully this is not something that will put network operators off
from provisioning IPv6(-only) connectivity to the Apple devices on
their network...

> The NAT64 test mode was designed to help developers ensure that their
> app can still function with IPv6-only NAT64+DNS64 connectivity and
> communicate with their IPv4 server, even if the developer does not
> have access to the IPv6 internet. That NAT64 network does not have
> IPv6 connectivity to the global IPv6 internet. As such, the current
> version advertises addresses from 2001::/64 instead of ULAs to
> simulate real IPv6 connectivity, as all IPv6 packets are terminated
> at the NAT64 server on the Mac. This implementation detail could
> change in the future.

One thing that is not clear to me, is if what happens if the app
developer's server is dual-stacked. For example, if the DNS entries are
as follows:

www.example.com. IN A 192.0.2.1
www.example.com. IN AAAA 2001:db8::1

...what exactly happens when the iOS node on the NAT64 testing WLAN
attempts to access it? Obviously, as there is no connectivity to
2001:db8::1, native IPv6 towards the "IN AAAA" record cannot work.

Does the DNS64 in the OS X host consider "::/0" as part of the Special
Exclusion Set (cf. RFC6146 s5.1.4), causing it to ignore the upstream
AAAA record and perform DNS64 synthesis instead, e.g., returning this
to the tethered host:

www.example.com. IN A 192.0.2.1
www.example.com. IN AAAA 2001::192.0.2.1

Or will it simply return the upstream DNS records verbatim (i.e., not
performing any DNS64 synthesis), and rely on the Happy Eyeballs
implementation in the iOS node to quickly figure out that the
2001:db8::1 address is unreachable and fail over to 192.0.2.1 (at which
point the Bump-in-the-API can kick in and perform local translation to
2001::192.0.2.1)?

Or perhaps something else entirely?

> *) Making IPv4 literals work on NAT64 networks when using high-level
> APIs Starting with this year's versions, if you use NSURLSession to
> connect to an IPv4 literal on an IPv6-only NAT64-DNS64 network, the
> API will bump in a IPv6 literal synthesized using RFC 7050. Note that
> this will not happen when using sockets directly. We do not support
> under-the-sockets bump-in-API (RFC 3338) and we do not support
> 464XLAT.

Does this mean that if the app is using socket directly, but in a
correct and IPv6-supporting way, to either:

1) communicate with dual-stacked hostnames (assuming ::/0 is not in the
DNS64's Special Exclusion Set as per what I wrote earlier), or
2) directly to an IPv6 literal address (think for example peer-to-peer
applications/protocols that do not use DNS to begin with),

..will then any tests for correct IPv6-only app behaviour the developer
performs on the NAT64 network fail, even though the app is doing
everything right?

A related question: Will the test system that validates App Store
submissions for correct IPv6-only behaviour have full access to the
entire IPv6 Internet, ensuring that apps such as the above will be
approved, even though they might not work correctly behind an OS X
NAT64-only test network?

> *) Happy Eyeballs
> We've heard feedback on our Happy Eyeballs implementation and are
> investigating this topic.

Great! Let me add my voice to this: Please ensure that IPv6 is
consistently preferred over IPv4, if both protocols work equally
well/fast (or roughly so). Only fall back on IPv4 it is clear that IPv6
is performing *significantly* worse than IPv4, or not at all. See
RFC6555 s4.1.

Tore

---

From: Ross Chandler <[email-masked]>
Date: Sat, 20 Jun 2015 12:31:03 +0100

Hi David,

Thanks for working towards supporting the IPv6-only carrier case!

Not all visited operators can yet be relied on to allow dual-stack or even IPv6-only bearers.
Does it support fallback to an IPv4-only bearer when data roaming?

Also could you clarify what the position will be with VPN support?

Ross

> On 19 Jun 2015, at 22:46, David Schinazi <[email-masked]> wrote:
> 
> Hi everyone,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Jun 2015 13:22:05 +0200

Hi,

Thanks for the report.  I have a few comments.

Le 19/06/2015 23:46, David Schinazi a écrit :
[...]
> *) Personal hotspot on iOS If your iPhone has dual-stack connectivity
> on its cellular network, the hotspot it creates will be dual-stack as
> well. The phone will share its prefix with Wi-Fi clients.

The way of sharing a prefix with the Wi-Fi Clients is supposedly the one
documented in RFC7278 "Extending an IPv6 /64 Prefix from a Third
Generation Partnership Project (3GPP) Mobile Interface to a LAN Link"
https://tools.ietf.org/html/rfc7278

That is straightforward to implement yet it does have some drawbacks.

The most important drawback of 64share IMHO is that the smartphone can 
not make two hotspots simultaneouly: one on WiFi and one on Bluetooth. 
Or otherwise one on WiFi5GHz and one on WiFi2.4GHz.  Or several subnets 
in a car connected with an Apple phone to the Internet.  Because it is 
impossible to share a unique /64 prefix to more than just one subnet.

It is better to tell the operator to provide a /63 to smartphones (not a
/64), with DHCPv6 Prefix Delegation.  That will fix it.

> *) Internet Sharing on the Mac Today, regular internet sharing (from
>  your ethernet to Wi-Fi for example) does not support IPv6 because of
>  the limited use cases, and the lack of demand for it.

If you get done the above then you get Internet Sharing on the Mac Today
as well, for free.

> *) Internet Sharing on the Mac - NAT64 testing mode The NAT64 test
> mode was designed to help developers ensure that their app can still
> function with IPv6-only NAT64+DNS64 connectivity and communicate with
> their IPv4 server, even if the developer does not have access to the
> IPv6 internet. That NAT64 network does not have IPv6 connectivity to
> the global IPv6 internet. As such, the current version advertises
> addresses from 2001::/64 instead of ULAs to simulate real IPv6
> connectivity, as all IPv6 packets are terminated at the NAT64 server
>  on the Mac. This implementation detail could change in the future.

Makes sense.

Alex

>  API will bump in a IPv6 literal synthesized using RFC 7050. Note
> that this will not happen when using sockets directly. We do not
> support under-the-sockets bump-in-API (RFC 3338) and we do not
> support 464XLAT.
>
> *) Happy Eyeballs We've heard feedback on our Happy Eyeballs
> implementation and are investigating this topic.
>
> Note that this reflects how these technologies work in the current
> versions of the 2015 betas, many of these details could change in
> future betas. Please keep in mind that these betas are previews and
> we welcome feedback on improving them.
>
> Thanks, David Schinazi Apple CoreOS Networking Engineer
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Jeremy Visser <[email-masked]>
Date: Mon, 22 Jun 2015 21:45:14 +1000

> /64), with DHCPv6 Prefix Delegation.  That will fix it.

Why stop at /63?

If you can think of a use for two subnets, I can think of a use for three.  Or four.  Or sixteen.  Or two hundred and fifty-six...

---

From: Gert Doering <[email-masked]>
Date: Mon, 22 Jun 2015 14:03:54 +0200

Hi,

On Mon, Jun 22, 2015 at 09:45:14PM +1000, Jeremy Visser wrote:
> I can think of a use for three.  [..] Or two hundred and fifty-six...

You can?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 22 Jun 2015 12:13:35 +0000

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Jeremy Visser
Sent: Monday, June 22, 2015 7:45 AM
To: [email-masked]
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share

>If you can think of a use for two subnets, I can think of a use for three.  Or four.  Or sixteen.  Or two hundred and fifty-six...

Also, if the phone uses DHCPv6 PD, then the phone's interface is a requesting router as per RFC3633.  Note, the IPv6 CE Router document in RFC7084 and its WPD-2 bullet.  One should round off prefix length to the nearest nibble.  Thus use a /60.    Additionally, since the phone has disparate transport interfaces in cellular and wifi to forward traffic between, it is best to use routing between the two interfaces.  See what subset of rfc7084 can be used in the phone.  Additionally, an IPv6 CE router implementation is available on Linux in OpenWRT for Linksys routers. 

Thanks,

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 22 Jun 2015 14:16:50 +0200 (CEST)

> /64), with DHCPv6 Prefix Delegation.  That will fix it.

DHCPv6-PD exists in recent 3GPP documents, but vendor implementation of 
this is not wide-spread. We do *not* want to gate IPv6 rollout in mobile 
networks on this functionality. Yes, we want it, but we can't wait for it.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ross Chandler <[email-masked]>
Date: Mon, 22 Jun 2015 13:24:35 +0100

> On 22 Jun 2015, at 13:16, Mikael Abrahamsson <[email-masked]> wrote:
> 
>> It is better to tell the operator to provide a /63 to smartphones (not a /64), with DHCPv6 Prefix Delegation.  That will fix it.
> 
> DHCPv6-PD exists in recent 3GPP documents, but vendor implementation of this is not wide-spread. We do *not* want to gate IPv6 rollout in mobile networks on this functionality. Yes, we want it, but we can’t wait for it.

Agreed. Also L2 bridging and 64share can be used to simultaneously provide IPv6 over WiFi, Bluetooth, and wired Ethernet.

Ross

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 22 Jun 2015 14:01:52 +0000

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Ross Chandler
Sent: Monday, June 22, 2015 8:25 AM
To: Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share

>Agreed. Also L2 bridging and 64share can be used to simultaneously provide IPv6 over WiFi, Bluetooth, and wired Ethernet.

Please go back to v6ops mailer archive and see sometime between 2008-2010 we have already commented on a cellular phone supporting bridging.   Then one's home TV such as Apple TV packets leak from the wifi to the cellular network via the bridging on the phone.  Now one just clogged the cellular network with video.

Hemant

---

From: Ross Chandler <[email-masked]>
Date: Mon, 22 Jun 2015 15:28:08 +0100

> On 22 Jun 2015, at 15:01, Hemant Singh (shemant) <[email-masked]> wrote:
> 

Are you arguing for DHCPv6-PD prior to the stopgap of L2 bridging and 64share? I’ve seen this implemented in UEs.

Ross

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Jun 2015 16:33:07 +0200

> Feel free to contact me if you have any questions, I will also attend IETF93.

Ok, here's some feedback on happy eyeballs, to the list so maybe others can improve upon it.

It would be extremely useful to be able to temporarily force IPv6 first or IPv4 first rather than have happy eyeballs for testing purposes.

At NANOG and the RIPE meeting recently, people have presented results that show that IPv6 frequently performs better than IPv4, although the RTT isn't better. It's unclear why this is, but my theory is that the correlation between networks with good performance and networks with IPv6 enabled is high and thus sometimes the IPv4 path goes through a "bad" IPv4-only network which obviously isn't available to IPv6 packets, which then flow through an alternative IPv6-enabled path over a "good" network.

The extra 20 bytes of IPv6 header add about 25% to a SYN while data packets are the same 1500 bytes. So if you guys currently look at the RTT for the three-way handshake, it would probably help if you could look at the RTT for data packets instead.

And maybe the RTT is the same but the (congestion) window is smaller on IPv4. Perhaps a NAT messes with the window scale option? So maybe look at the IPv4 vs IPv6 window sizes. I would suggest something along these lines:

if v4RTT < v6RTT - 25 then return IPv4
if v4window / v4RTT > v6window / v6RTT * 1.2 then return IPv4
return IPv6

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.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 22 Jun 2015 14:47:38 +0000

-----Original Message-----
From: Ross Chandler [mailto:[email-masked]] 
Sent: Monday, June 22, 2015 10:28 AM
To: Hemant Singh (shemant)
Cc: Mikael Abrahamsson; [email-masked]
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share

>Are you arguing for DHCPv6-PD prior to the stopgap of L2 bridging and 64share? I’ve seen this implemented in UEs.

It's up to the provider to deploy what they choose to deploy.   I am only discussing pitfalls with each tech being considered for deployment.  I do have a preference for DHCPv6 PD and routing.  The reason is DHCPv6 PD and IPv6 CE router can support all of wifi, Bluetooth, etc.  Additionally, devices such as Apple TV in the home can be assigned ULAs which the router on the phone will never forward to the WAN - thus no video from the home leaks to the cellular network.  I will never consider a technology that leaks a home's  TV video to the cellular network.  

Hemant

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Jun 2015 17:11:03 +0200

Le 22/06/2015 14:24, Ross Chandler a écrit :
>>> It is better to tell the operator to provide a /63 to
>>> smartphones (not a /64), with DHCPv6 Prefix Delegation.  That
>>> will fix it.
>>
>> DHCPv6-PD exists in recent 3GPP documents, but vendor
>> implementation of this is not wide-spread. We do *not* want to
>> gate IPv6 rollout in mobile networks on this functionality. Yes, we
>> want it, but we can’t wait for it.
>
> Agreed. Also L2 bridging and 64share can be used to simultaneously
> provide IPv6 over WiFi, Bluetooth, and wired Ethernet.

Yes, some can be bridged.

But only the bridgeable links can be bridged (802) - serial, CAN, USB,
wont bridge.

Some subnets could bridge yet won't - in order to avoid noise (safety vs
entertainment).

Some subnets route (not bridge) for scalability reasons.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Jun 2015 17:21:06 +0200

Le 22/06/2015 13:45, Jeremy Visser a écrit :
>> It is better to tell the operator to provide a /63 to smartphones
>> (not a /64), with DHCPv6 Prefix Delegation.  That will fix it.
>
> Why stop at /63?

I think cellular network architects are reluctant to leap from 64 to 63. 
  Once that leap is overcome the other prefix lenghs are just small steps.

> If you can think of a use for two subnets, I can think of a use for
> three.  Or four.  Or sixteen.  Or two hundred and fifty-six...

YEs, in a sense.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Mon, 22 Jun 2015 09:49:01 -0700

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

Pretty hard to look at the data RTT when establishing a connection. How do you see that working?

> if v4window / v4RTT > v6window / v6RTT * 1.2 then return IPv4

This may well have some merit.

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

+1

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

Wouldn’t that require bridging to between the real interface and the test interface rather than routing? Perhaps that’s not a bad idea, (the kernel already has the necessary bridging code), but a consistent and deterministic way of selecting bridge vs. route would be necessary to create a full test environment, IMHO.

Owen

---

From: Erik Nygren <[email-masked]>
Date: Mon, 22 Jun 2015 12:53:30 -0400

+1 to this

Having the NAT64/DNS64 environment is great for IPv6-only testing, but if
it doesn't provide the ability to get through to real IPv6
content/resources when the MacOS host has IPv6 connectivity (either
natively or via a tunnel) then it could be counter-productive in some
circumstances and could discourage app writers from developing their apps
to work well in scenarios where true end-to-end IPv6 connectivity is
possible.  Engineering and QA teams may instead focus purely on playing
well with NAT64/DNS64 than on also being able to avoid the NAT64 entirely
(which is clearly desirable for end-user performance.)

       Erik

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

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

---

From: Owen DeLong <[email-masked]>
Date: Mon, 22 Jun 2015 10:01:23 -0700

> On Jun 22, 2015, at 04:22 , Alexandru Petrescu <[email-masked]> wrote:
> 
> Hi,
> 
> The most important drawback of 64share IMHO is that the smartphone can not make two hotspots simultaneouly: one on WiFi and one on Bluetooth. Or otherwise one on WiFi5GHz and one on WiFi2.4GHz.  Or several subnets in a car connected with an Apple phone to the Internet.  Because it is impossible to share a unique /64 prefix to more than just one subnet.

Not entirely true. True, you cannot have multiple subnets. This is true in any situation where the device in question receives only one /64 (unless you make absurd small subnets).

However, in the case of hotspot on 5, 2.4, and BT, as long as the phone can bridge them all together as a single subnet, that’s perfectly viable. If the phone wants to treat them as routed interfaces, then it breaks.

> /64), with DHCPv6 Prefix Delegation.  That will fix it.

No… If you’re going to go to PD, a /63 is stupid. Ideally, use a /48, but at least provide enough subnets to cover BT, USB, 2.4, and 5Ghz plus some headroom for future applications.

> If you get done the above then you get Internet Sharing on the Mac Today

Since iOS and OSX  are separate code bases, I’m not sure why you think that.

>> on the Mac. This implementation detail could change in the future.

Not really… This address is currently in the IANA free pool. It could be
assigned to an RIR and then put on a real network at any point in the
future.

It would be much better to use a /64 Apple can set aside from their own space
or some other block of addresses registered for this purpose… Heck, worst
case, Apple could sign up for a free tunnel from HE and burn the /64
assigned to that tunnel.

Ideally, the prefix should be user configurable as well.

>> support under-the-sockets bump-in-API (RFC 3338) and we do not

They really should support 464XLAT at this point IMHO, though some of
what they are doing may obviate or lessen the need. It will be interesting
to see if this is sufficient for T-Mo to finally turn on IPv6 for my phone.

Ideally, T-Mo should pull their head out of their ass about dual-stack and
Apple should pull their head out of their ass about 464XLAT, but either
one would meet my immediate needs. Unfortunately, they’re both sitting
there playing internet chicken waiting for the other one to blink.

Given the number of other cellular networks that are following the same
path as T-Mo, I think mass is on their side, but Apple may be too stubborn
to blink and a head-on may be inevitable.

Unfortunately, it’s the end-users that will be the victims in this crash, not
the drivers.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 22 Jun 2015 10:06:23 -0700

> On Jun 22, 2015, at 07:47 , Hemant Singh (shemant) <[email-masked]> wrote:
> 

Why not? I’m pretty annoyed that I have to use the HTTP interface and wifi hotspot on my phone rather than the iOS App to pull video off of my TiVO when I’m not home.

Mostly this is because TiVO has their head up their ass about thinking:

	1.	All homes have one and only one broadcast domain.
	2.	TiVO won’t use the cellular interface on an iOS device. (It will connect over wifi just fine).

Sometimes I use one iOS device in hotspot mode to watch video on another which thinks it’s on wifi but is actually using the cellular network from the first iOS device.

All of these limitations on how I use the cellular bandwidth I pay for are:
	1)	Silly
	2)	Annoying
	3)	Unnecessary

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Jun 2015 22:07:30 +0200

On 22/06/2015 19:01, Owen DeLong wrote:
>> Le 19/06/2015 23:46, David Schinazi a écrit : [...]
>>> *) Personal hotspot on iOS If your iPhone has dual-stack
>>> connectivity on its cellular network, the hotspot it creates
>> The way of sharing a prefix with the Wi-Fi Clients is supposedly
>> the one documented in RFC7278 "Extending an IPv6 /64 Prefix from a
>> Third Generation Partnership Project (3GPP) Mobile Interface to a
>> LAN Link" https://tools.ietf.org/html/rfc7278
>>
>> The most important drawback of 64share IMHO is that the smartphone
>> can not make two hotspots simultaneouly: one on WiFi and one on
>> Bluetooth. Or otherwise one on WiFi5GHz and one on WiFi2.4GHz.  Or
>> several subnets in a car connected with an Apple phone to the
>> Internet.  Because it is impossible to share a unique /64 prefix
>> to more than just one subnet.
>
> Not entirely true. True, you cannot have multiple subnets. This is
> true in any situation where the device in question receives only one
> /64 (unless you make absurd small subnets).
>
> However, in the case of hotspot on 5, 2.4, and BT, as long as the
> phone can bridge them all together as a single subnet, that’s
> perfectly viable.

Yes.  It can bridge those which are bridgeable.

Bridging point-to-point bluetooth link to the dashboard and the
broadcast WiFi car hotspot is not working.

Safety and entertainment subnets in a car which must not be bridged for
reliability reasons (don't noise the safety messages) - is not working 
either zith 64share.

Bridging Bluetooth and WiFi ha no link-layer security.

> If the phone wants to treat them as routed interfaces, then it
> breaks.

Yes, 64share breaks in routed subnets.

> No… If you’re going to go to PD, a /63 is stupid. Ideally, use a
> /48,

Well, one cellular network operator has a /47 to 'share' with all its
customer UEs.  If that operator gave a /48 to an UE it could satisfy 
only 2 such customers, not millions.

> but at least provide enough subnets to cover BT, USB, 2.4, and 5Ghz
> plus some headroom for future applications.

I agree, headroom should be provided.

>>> *) Internet Sharing on the Mac Today, regular internet sharing
>>> (from your ethernet to Wi-Fi for example) does not support IPv6
>>> because of the limited use cases, and the lack of demand for it.
>>
>> If you get done the above then you get Internet Sharing on the Mac
>> Today as well, for free.
>

Because the DHCPv6 Prefix Delegation is a userspace application
implementing a protocol - suffices it to compile on each of these
code bases.  It acts the same everywhere.

It's not a GUI, or some kernel module, or some AF-dependent software.

>>> *) Internet Sharing on the Mac - NAT64 testing mode The NAT64
>>> test mode was designed to help developers ensure that their app
>>> can still function with IPv6-only NAT64+DNS64 connectivity and
>>> communicate with their IPv4 server, even if the developer does
>>> not have access to the IPv6 internet. That NAT64 network does
>>> not have IPv6 connectivity to the global IPv6 internet. As such,
>>> the current version advertises addresses from 2001::/64 instead
>>> of ULAs to simulate real IPv6 connectivity, as all IPv6 packets
>>> are terminated at the NAT64 server on the Mac. This
>>> implementation detail could change in the future.
>>
>> Makes sense.
>>
>
> Not really… This address is currently in the IANA free pool. It
> could be assigned to an RIR and then put on a real network at any
> point in the future.
>
> It would be much better to use a /64 Apple can set aside from their
> own space or some other block of addresses registered for this
> purpose… Heck, worst case, Apple could sign up for a free tunnel
> from HE and burn the /64 assigned to that tunnel.
>

I think I didnt read the message as you did.

I assume by 2001::/64 is meant actually 2001::/3, or some other
2001:X:Y:U:Z::/64 that the operator prodived.  I think it was said
2001::/3 to distiguish from ULA fd00::/something, and so I said it made
sense.

And, if what is said is really meaning 2001::/64 then I agree with you -
that's at IANA and one wouldn't juggle with 2001::/64 just like that.
If one wants to juggle with something then it's with fd00::/64
(ULA) and with 2001:db8::/32 (docu prefix).

>>> *) Making IPv4 literals work on NAT64 networks when using
>>> high-level APIs Starting with this year's versions, if you use
>>> NSURLSession to connect to an IPv4 literal on an IPv6-only
>>> NAT64-DNS64 network, the API will bump in a IPv6 literal
>>> synthesized using RFC 7050. Note that this will not happen when
>>> using sockets directly. We do not support under-the-sockets
>>> bump-in-API (RFC 3338) and we do not support 464XLAT.
>
> what they are doing may obviate or lessen the need. It will be
> interesting to see if this is sufficient for T-Mo to finally turn on
> IPv6 for my phone.
>
> Ideally, T-Mo should pull their head out [...] about dual-stack and
> Apple should pull their head out [...] about 464XLAT, but either one
> would meet my immediate needs.

I wouldnt put it that blunt.  But I would agree that less transitioning 
be faster transition.

> Unfortunately, they’re both sitting there playing internet chicken
> waiting for the other one to blink.
>
> Given the number of other cellular networks that are following the
> same path as T-Mo, I think mass is on their side, but Apple may be
> too stubborn to blink and a head-on may be inevitable.

I think I agree with you.  I am very happy one particular operator leads 
with IPv6 deployment in a successful way.  But I am very unhappy that 
operation is taken blindly as an example by other operators.  It has 
drawbacks.

> Unfortunately, it’s the end-users that will be the victims in this
> crash, not the drivers.

To be seen.

Alex

> Owen

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com

---

From: Owen DeLong <[email-masked]>
Date: Mon, 22 Jun 2015 13:50:26 -0700

> customer UEs.  If that operator gave a /48 to an UE it could satisfy only 2 such customers, not millions.

That is a problem that is easy to solve with a simple interaction with their RIR.

Give me a break.

We should not be designing around providers that didn’t ask for enough IPv6 space
for their deployments. We should educate those providers. IPv6 space is easy
to get. A cellular network is an ISP almost by definition.

There isn’t a single RIR on the planet that won’t grant you at least a /32
if you walk up and say “I’m an ISP, /32 please” in any credible way.

(modulo payment of fees, etc., but you get the point)

> code bases.  It acts the same everywhere.

Yes and no.

> It's not a GUI, or some kernel module, or some AF-dependent software.

Well… It is actually AF-dependent. DHCPv6 will not work on IPv4 very well at all.

> 2001::/3 to distiguish from ULA fd00::/something, and so I said it made

I heard 2001::/64 and took them at their word. If 2001::/64 is a mistake and they’re
using something legitimate, then no problem. If I misheard, then also no problem.

Either is possible.

> (ULA) and with 2001:db8::/32 (docu prefix).

I have a problem with putting 2001:db8::/32 on actual hardware… I think that
violates its intended purpose in the vast majority of cases, including this one.

It shouldn’t be too hard for Apple to come up with a /64 they can delegate to this
safely.

Beyond that, I still think that having it be user configurable is desirable for a wider
range of testing scenarios to be supported.

> I wouldnt put it that blunt.  But I would agree that less transitioning be faster transition.

I’ve tried polite… They haven’t listened. Maybe if I’m blunt it will get their attention.

If you have another alternative that might work, I’m open to it.

> I think I agree with you.  I am very happy one particular operator leads with IPv6 deployment in a successful way.  But I am very unhappy that operation is taken blindly as an example by other operators.  It has drawbacks.

Actually, T-Mo DOES NOT LEAD. Verizon led and was _WAY_ ahead of T-Mo and implemented dual-stack.

Owen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Jun 2015 22:50:36 +0200

On 22 Jun 2015, at 18:49, Owen DeLong <[email-masked]> wrote:

>> So if you guys currently look at the RTT for the three-way handshake, it would probably help if you could look at the RTT for data packets instead.

> Pretty hard to look at the data RTT when establishing a connection. How do you see that working?

I don't know the details of Apple's (or anyone else's) happy eyeballs implementation. If they set up connections, measure the RTT for the three three-way handshake and then abandon the higher RTT session, or initiate connections in parallel and only pursue the one that connects first, then you're right, this would be a problem. On the other hand, if they do an HTTP request over IPv4 and one over IPv6, then an RTT for data segments would be available.

> Wouldn’t that require bridging to between the real interface and the test interface rather than routing? Perhaps that’s not a bad idea, (the kernel already has the necessary bridging code), but a c…

Hm, if native IPv6 is available on interface A but you want to run your test NAT64 network on interface B and thus need to bridge A and B, why wouldn't you just cut out the middleman and run your test NAT64 network on interface B?

Likely answer: because B is actually dual stack and you need to keep out the IPv4. So then not only would you have to bridge the IPv6, you would have to filter out the IPv4 while doing that. That seems a tall order.

A much simpler solution is to simply route a /64 to the interface that hosts the test NAT64 network. Obviously if you have consumer-level native IPv6 that won't always be possible because you only get a /64 and/or a way to route additional subnets through cascading DHCPv6 PD or an IPv6 routing protocol isn't supported.

But if all else fails you can terminate a tunnel broker (.net) tunnel on your Mac and route a /64 to the desired interface and turn on IPv6 forwarding in the kernel.

If Apple is interested in solving more of this than just allowing us to set up our own IPv6 addresses on the test NAT64 interface (which is the only part we need Apple to make possible, we can do the rest ourselves) then IPv6 bridging with IPv4 blocking would be a good choice because then you can easily take advantage of native IPv6 on an interface without automatically getting the IPv4 that virtually always comes with it.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Jun 2015 22:51:53 +0200

On 22 Jun 2015, at 18:53, Erik Nygren <[email-masked]> wrote:

> Having the NAT64/DNS64 environment is great for IPv6-only testing, but if it doesn't provide the ability to get through to real IPv6 content/resources when the MacOS host has IPv6 connectivity (either natively or via a tunnel) then it could be counter-productive in some circumstances and could discourage app writers from developing their apps to work well in scenarios where true end-to-end IPv6 connectivity is possible.

Hm, what kind of stuff would work through NAT64 that wouldn't work with real IPv6 connectivity?

(Thinking of stuff that _would_ work with real IPv6 but not NAT64 is easier.)

---

From: james woodyatt <[email-masked]>
Date: Mon, 22 Jun 2015 14:26:51 -0700

> (Thinking of stuff that _would_ work with real IPv6 but not NAT64 is easier.)

An obvious example would be a UDP application that depends on a 1500 octet path MTU to all the IPv6 destinations it cares about. The NAT64 will shave a 1500 octet packet down to 1480, which might make it everywhere you want to go over IPv4 without needing to handle ICMPv6 Packet Too Big Errors, leaving you to discover later that native IPv6 destinations require you to deal with paths that are 1492 octets and not 1500 octets.

I’m sure if I think for a few minutes, I might be able to come up with another one. There are probably TCP cases like this too given the way ICMP6 filters seem to be so terribly popular despite the guidance our humble working group tries to provide.

—james

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Jun 2015 23:47:49 +0200

> An obvious example would be a UDP application that depends on a 1500 octet path MTU to all the IPv6 destinations it cares about. The NAT64 will shave a 1500 octet packet down to 1480, which might m…

Sure. Except that the kernel will handle all your fragmentation needs invisibly to the application (well, save for a retransmission or two). And testing with native IPv6 won't catch this most of the time anyway, as 65% of all paths (in my very limited measurements, but still) are 1500-byte clean.

Also, I certainly hope application writers aren't going to test their applications for compatibility with networks that filter ICMPv6 too bigs, that would be insanity.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 22 Jun 2015 14:53:15 -0700

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

The few tcpdump logs I’ve looked at would seem to indicate that most (including Apple’s) HE implementations I’ve encountered do the former rather than the latter. Also as near as I can tell, state isn’t tracked from one connection to the next, each new connect() loop sprays a new set of SYNs and then abandons all but the one it selects.

YMMV

Owen

---

From: Paul Saab <[email-masked]>
Date: Mon, 22 Jun 2015 22:17:19 +0000

On Mon, Jun 22, 2015 at 2:53 PM Owen DeLong <[email-masked]> wrote:

> The few tcpdump logs I’ve looked at would seem to indicate that most
> (including Apple’s) HE implementations I’ve encountered do the former
> rather than the latter. Also as near as I can tell, state isn’t tracked
> from one connection to the next, each new connect() loop sprays a new set
> of SYNs and then abandons all but the one it selects.
>

With the help of Jason Fesler and his test-ipv6 infrastructure, Apple has a
good way to validate that their HE will not penalize IPv6 any longer.  Even
in the first iOS9 release, the current HE still penalizes IPv6 when RTT is
the same or within their "fudge factor", so thankfully we now have a good
test for them to work against.  Let's just wait for the seed that contains
the changes and test again.

---

From: james woodyatt <[email-masked]>
Date: Mon, 22 Jun 2015 15:42:06 -0700

> Also, I certainly hope application writers aren't going to test their applications for compatibility with networks that filter ICMPv6 too bigs, that would be insanity.

I think you might have overlooked where I wrote “UDP” above instead of “TCP” which on iOS and OS X doesn’t have any PMTUD support. The kernel will not do any fragmentation or retransmission of UDP packets. A lot of applications are coded never to process the error code at a socket if a Too Big error is received. They either ignore the error and fail because packet size are never reduced, or they fail inappropriately rather than reduce packet sizes. Developers who only use the NAT64 environment without testing on a native IPv6 network may never see the Too Big errors that would expose this problem, and they won’t see it until their application is deployed for reals.

—james

---

From: Ca By <[email-masked]>
Date: Mon, 22 Jun 2015 15:58:56 -0700

On Monday, June 22, 2015, james woodyatt <[email-masked]> wrote:

> On Jun 22, 2015, at 14:47, Iljitsch van Beijnum <[email-masked]
> <javascript:;>> wrote:
> > On 22 Jun 2015, at 23:26, james woodyatt <[email-masked]
> <javascript:;>> wrote:
> >
> >> An obvious example would be a UDP application that depends on a 1500
> octet path MTU to all the IPv6 destinations it cares about. The NAT64 will
> shave a 1500 octet packet down to 1480, which might make it everywhere you
> want to go over IPv4 without needing to handle ICMPv6 Packet Too Big
> Errors, leaving you to discover later that native IPv6 destinations require
> you to deal with paths that are 1492 octets and not 1500 octets.
> >
> > Sure. Except that the kernel will handle all your fragmentation needs
> invisibly to the application (well, save for a retransmission or two). And
> testing with native IPv6 won't catch this most of the time anyway, as 65%
> of all paths (in my very limited measurements, but still) are 1500-byte
> clean.
> >
> > Also, I certainly hope application writers aren't going to test their
> applications for compatibility with networks that filter ICMPv6 too bigs,
> that would be insanity.
>
> I think you might have overlooked where I wrote “UDP” above instead of
> “TCP” which on iOS and OS X doesn’t have any PMTUD support. The kernel will
> not do any fragmentation or retransmission of UDP packets. A lot of
> applications are coded never to process the error code at a socket if a Too
> Big error is received. They either ignore the error and fail because packet
> size are never reduced, or they fail inappropriately rather than reduce
> packet sizes. Developers who only use the NAT64 environment without testing
> on a native IPv6 network may never see the Too Big errors that would expose
> this problem, and they won’t see it until their application is deployed for
> reals.
>
>
> —james

For some subset of networks, devs can test the real production deal if
apple could surface the apn setting in dev builds. It is hard to see the
harm in this. Other OSs allow apn setting fiddling. Also, this allows an
escape hatch for the inevitable user who cannot deal with ipv6-only in
production... And opens the door for end user opt in trials of ipv6.

It's really not a hard problem to solve for many situations (like tmus)
but the some backwards place .... They may not have this luxury of proper
ipv6 in mobile :/

CB

> [email-masked] <javascript:;>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Jun 2015 09:11:33 +1000

In message <[email-masked]>, Owen DeLong write
s:
> >> No...
> >> If you're going to go to PD, a /63 is stupid. Ideally, use a /48,
> >
> We should not be designing around providers that didn't ask for enough
> IPv6 space for their deployments. We should educate those providers.
> IPv6 space is easy to get. A cellular network is an ISP almost by definition.
>
> There isn't a single RIR on the planet that won't grant you at least a /32
> if you walk up and say "I'm an ISP, /32 please" in any credible way.
>
> >> Since iOS and OSX  are separate code bases, I'm not sure why you
> >> think that.
> >
> Well...
>  It is actually AF-dependent. DHCPv6 will not work on IPv4 very well at
> all.
>
> >> Not really...
> >>  This address is currently in the IANA free pool. It
> >> purpose...
> >>  Heck, worst case, Apple could sign up for a free tunnel
> I heard 2001::/64 and took them at their word. If 2001::/64 is a mistake
> and they're
> I have a problem with putting 2001:db8::/32 on actual hardware...
> I think that violates its intended purpose in the vast majority of
> cases, including this one.
>
> It shouldn't be too hard for Apple to come up with a /64 they can
> delegate to this safely.
>
> Beyond that, I still think that having it be user configurable is
> desirable for a wider range of testing scenarios to be supported.
>
> >
> I've tried polite...
>  They haven't listened. Maybe if I'm blunt it will get their attention.
>
> If you have another alternative that might work, I'm open to it.
>
> >
> >> Unfortunately, they're both sitting there playing internet chicken
> > I think I agree with you.  I am very happy one particular operator
> > leads with IPv6 deployment in a successful way.  But I am very unhappy
> > that operation is taken blindly as an example by other operators.  It has
> > drawbacks.
>

464XLAT with DNS64 is a ABOMINATION.  The sooner it is removed the
better.  It only APPEARS to work well at the moment because there
is not a lot of validation happening in the application yet.  It
does not work with a validating recursive nameservers forwarding
queries to a DNS64 recursive server.

MAP and DS-Lite both do a better job and neither of them muck with
packet payload.  They also work with DNSSEC (464XLAT is usually
deployed with DNS64 and DNS64 DOES NOT WORK WITH DNSSEC (CD=1 does
NOT indicate validation is occuring despite what is written in RFC
6147, DO=1 is the ONLY indicatator that validation MAY be occuring.)).

All three have PMTU issues.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Mon, 22 Jun 2015 16:18:15 -0700

On Jun 22, 2015, at 15:57, Iljitsch van Beijnum <[email-masked]> wrote:
> On 23 Jun 2015, at 0:42, james woodyatt <[email-masked]> wrote:
> 
>> I think you might have overlooked where I wrote “UDP” above instead of “TCP” which on iOS and OS X doesn’t have any PMTUD support. The kernel will not do any fragmentation or retransmission of UDP packets.
> 
> No, I didn't overlook that part. But let me return the favor: I think you're confusing IPv6 with IPv4 here. In IPv6, fragmentation is an IP-level function on the host.

I’m not confused about that.

> As such: […] I'm 99.9% sure this works the same way for UDP as for ICMPv6; […]

It does.

> You're right about the retransmission part, though, the first packet (the one that triggers the too big) is lost. If the return packet (for the retransmission) is also large, that one will very likely also be lost and cause the too big in the other direction, so it takes two retransmissions to get a reply.

The problem is that you can send those 1500 octet packets out your Wi-fi, and the NAT64 will shorten them to 1480 when it replaces the IPv6 header with an IPv4 header. Those 1480-octet IPv4 packets will then pass straight through parts of the network with PMTU=1492 without generating errors and therefore never exercising any application layer logic needed to deal with UDP-PMTUD, which is typically not there at all because developers are… well, they often don’t do it. Hence, you have something that works on NAT64 that will fail when they encounter native IPv6 and PMTU=1492, which is as we all know, not as uncommon as we’d like it to be.

—james

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Jun 2015 01:31:30 +0200

So then why would this be a problem:

> pass straight through parts of the network with PMTU=1492 without generating errors and therefore never exercising any application layer logic needed to deal with UDP-PMTUD, which is typically not there at all because developers are… well, they often don’t do it.

What exactly are you objecting to? That the translated packets are too small to trigger too bigs? That also happens with native IPv6 if the path supports 1500 bytes. So if you want to test for paths with < 1500 PMTUs, you will have to, you know, do the work to test with paths with < 1500 PTMUs.

If your problem is that applications don't handle incoming too bigs, then be glad you're behind a NAT64 because this is indeed a problem with IPv4 (but easily solved by simply setting the DF bit to 0!) but it isn't for IPv6, as we just agreed that with IPv6, the IP layer catches too bigs and fragments subsequent packets without involvement from the application.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 22 Jun 2015 17:03:18 -0700

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

Let me try and get you guys to stop talking across each other…

The issue James has (rightly, IMHO) raised is that at the application developer level, you may or may not think to test for <1500 MTU.

However, if you test your 1500-octet packet using application in a NAT64 environment and it works (because you’re connecting to an IPv4 server via a NAT that shortens your packets) and you think everything is wonderful and ship your application, it could come as a rude shock to your end-users who happen to have native IPv6 that wasn’t available in your development environment because all of a sudden, the 1500-octet packets you are sending are leaving the device as 1500-octet packets and dying in the wild rather than getting artificially shortened.

Thus, you’ve got a scenario where NAT64 testing is inadequate vs. NAT64 + Native V6 testing which was, in fact, the original question.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Jun 2015 10:06:43 +1000

In message <[email-masked]>, Iljitsch van Beijn
um writes:
> >> As such:  I'm 99.9% sure this works the same way for UDP as for 
> ICMPv6; 
> 
> > It does.
> 
> > pass straight through parts of the network with PMTU=1492 without 
> generating errors and therefore never exercising any application layer 
> logic needed to deal with UDP-PMTUD, which is typically not there at all 
> because developers are well, they often dont do it.
> 
> What exactly are you objecting to? That the translated packets are too 
> small to trigger too bigs? That also happens with native IPv6 if the path 
> supports 1500 bytes. So if you want to test for paths with < 1500 PMTUs, 
> you will have to, you know, do the work to test with paths with < 1500 
> PTMUs.
> 
> If your problem is that applications don't handle incoming too bigs, then 
> be glad you're behind a NAT64 because this is indeed a problem with IPv4 
> (but easily solved by simply setting the DF bit to 0!) but it isn't for 
> IPv6, as we just agreed that with IPv6, the IP layer catches too bigs and 
> fragments subsequent packets without involvement from the application.

For named (DNS) we just set IPV6_USE_MIN_MTU=1 for *both* TCP and
UDP.  PMTUD is a problem for TCP as well as UDP (load balancers /
filters).  We also send EDNS UDP requests with various response
sizes in the requests and look at actual response sizes because
there are idiots with firewalls that think dropping fragmented
packets is a good thing to do.

Unfortunately there are stacks that don't consider IPV6_USE_MIN_MTU
when performing MSS negotiation which is really wrong because when
it is set to 1 the MTU *is* 1280.  One really shouldn't have to
spell out the relationship.

[rock:~/git/bind9.drugs] marka% grep srtt /var/named/named_dump.db | grep udpsize | grep :
;	2620:74:19::33 [srtt 379894] [flags 00006000] [edns 10/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 218]
;	2610:a1:1014::78 [srtt 129911] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 444]
;	2001:502:cbe4::33 [srtt 163948] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 218]
;	2001:503:83eb::2:31 [srtt 317999] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 333]
;	2607:f208:302::30 [srtt 126230] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 434]
;	2001:500:2c::254 [srtt 228230] [flags 00006000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 1640] [ttl -116]
;	2001:67c:1010:13::53 [srtt 208027] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 437]
;	2001:500:e::1 [srtt 257600] [flags 00006000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266]
;	2a02:1788:0:600::c742:c805 [srtt 155908] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 444]
;	2001:500:71::30 [srtt 204866] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1652]
;	2001:500:90:1::27 [srtt 122709] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 268]
;	2001:500:7967::2:33 [srtt 120860] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 218]
;	2606:2800:1::5 [srtt 173309] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 270]
;	2400:cb00:2049:1::adf5:3b1f [srtt 115518] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266]
;	2001:dcd:5::101 [srtt 462281] [flags 00006000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 428]
;	2600:1401:1::41 [srtt 235626] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 218]
;	2001:500:1b::1 [srtt 434090] [flags 00006000] [edns 3/1/1/1/1] [plain 0/0] [udpsize 512] [ttl 439]
;	2407:6e00:253:306::73 [srtt 73080] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 432]
;	2400:cb00:2049:1::c629:de1f [srtt 116161] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266]
;	2001:500:94:1::20 [srtt 159376] [flags 00006000] [edns 3/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 268]
;	2001:dce:2000:2::130 [srtt 134191] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 437]
;	2600:1401:2::42 [srtt 176795] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 218]
;	2001:500:48::1 [srtt 180877] [flags 00006000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266]
;	2001:a10:121:1::156 [srtt 318167] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 267]
;	2001:500:90:1::20 [srtt 198783] [flags 00006000] [edns 3/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 268]
;	2a01:8840:6::1 [srtt 170706] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1652]
;	2001:502:ad09::14 [srtt 219604] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 437]
;	2600:1802:4::1 [srtt 174653] [flags 00006000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 436]
;	2620:0:150:4013::5 [srtt 298185] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 267]
;	2600:1401:2::ad [srtt 180765] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 436]
;	2001:500:94:1::34 [srtt 110366] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 269]
;	2606:2800:1::6 [srtt 116409] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 270]
;	2001:500:90::100 [srtt 215880] [flags 00006000] [edns 8/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 220]
;	2001:500:f::1 [srtt 133137] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266]
;	2001:503:a83e::2:31 [srtt 262167] [flags 00006000] [edns 18/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 333]
;	2001:dce:7000:2::130 [srtt 363522] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 437]
;	2001:4868:108:1:223:8bff:fea9:dbf8 [srtt 360151] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 260]
;	2001:502:ad09::3 [srtt 217370] [flags 00006000] [edns 2/1/0/0/0] [plain 0/0] [udpsize 512] [ttl 266]
;	2001:500:90:1::34 [srtt 118925] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 269]
;	2001:500:b::1 [srtt 146381] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266]
;	2001:1a68:0:17::238 [srtt 496218] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 267]
;	2001:500:4431::2:30 [srtt 291357] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 259]
;	2001:500:60::30 [srtt 187678] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1652]
;	2001:dcd:6::101 [srtt 534725] [flags 00006000] [edns 5/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 428]
[rock:~/git/bind9.drugs] marka%

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Jun 2015 02:11:15 +0200

> Thus, you’ve got a scenario where NAT64 testing is inadequate vs. NAT64 + Native V6 testing which was, in fact, the original question.

Like I said, if you want to test for paths that don't support 1500 byte path MTUs, please test with paths that don't support 1500 byte path MTUs rather than make assumptions based on the presence or absence of a packet size reducing apparatus.

But IPv6 UDP applications shouldn't concern themselves with testing for PMTUD black holes. This breaks TCP anyway, giving the user much bigger fish to fry. And IPv4 UDP applications should leave the DF bit alone because setting it to one can only end in tears.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Jun 2015 02:12:35 +0200

On 23 Jun 2015, at 2:06, Mark Andrews <[email-masked]> wrote:

> UDP.

So now application makers get to decide on TCP's segment size?

Fuck that.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 22 Jun 2015 17:17:14 -0700

> On Jun 22, 2015, at 17:11 , Iljitsch van Beijnum <[email-masked]> wrote:
> 
> On 23 Jun 2015, at 2:03, Owen DeLong <[email-masked] <mailto:[email-masked]>> wrote:
> 

And once again, Iljitsch lets religion get in the way of understanding the way the real world works…

Meanwhile, the rest of us realize that this isn’t a matter of someone who understands the issue deciding to test (or not) this scenario, but an issue of the use of a particular technology in the test environment obfuscating the issue in other environments thus calling for an expansion of the capabilities of the test environment.

Owen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Jun 2015 02:29:52 +0200

> And once again, Iljitsch lets religion get in the way of understanding the way the real world works…

That would be true if I were talking about IPv4 UDP applications not testing for PMTUD black holes. Which I also stand behind; the internet needs larger packets, so any action to artificially limit packet sizes is counterproductive.

But my point about IPv6 UDP applications is not religious, it's just simple common sense: if the protocol that occupies 85% of the internet's packets is going to fail anyway, why bother doing extra work to keep one particular application that occupies a small fraction of the remaining 15% running? (I.e., with unlike with IPv4, with IPv6, TCP and UDP have the same failure mode in the presence of PMTUD black holes. And if depending on PMTUD is too deemed dangerous, then 1280 is the answer, with no need for any testing.)

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 22 Jun 2015 20:33:33 -0400

Please remember to keep the tone professional.

Thank you,

Lee

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Jun 2015 10:33:39 +1000

> So now application makers get to decide on TCP's segment size?

Grow up.

Yes, application developers have applications that just don't work
with PMTUD.  IPV6_USE_MIN_MTU was add back at the turn of the century
for those applications.

For the DNS, where unless you are pipelining DNS queries at a server
or performing a zone transfer, all DNS transactions are less than
64K and 99.99999% are less than 4K the difference between 1280 and
1500 is a few of extra packets (for both UDP and TCP).  DNS also
has much tighter real life timing constraints than most applications.

Mark

---

From: Owen DeLong <[email-masked]>
Date: Mon, 22 Jun 2015 17:34:38 -0700

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

Because the tests against TCP are going to notice the problem where the problem may get masked for UDP  without the developer ever being the wiser.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Jun 2015 10:58:56 +1000

In message <[email-masked]>, Iljitsch van Beijnum writes:
> >> But IPv6 UDP applications shouldn't concern themselves with testing 
> for PMTUD black holes. This breaks TCP anyway, giving the user much 
> bigger fish to fry. And IPv4 UDP applications should leave the DF bit 
> alone because setting it to one can only end in tears.
> 
> > And once again, Iljitsch lets religion get in the way of understanding 
> the way the real world works
> 
> That would be true if I were talking about IPv4 UDP applications not 
> testing for PMTUD black holes. Which I also stand behind; the internet 
> needs larger packets, so any action to artificially limit packet sizes is 
> counterproductive.
> 
> But my point about IPv6 UDP applications is not religious, it's just 
> simple common sense: if the protocol that occupies 85% of the internet's 
> packets is going to fail anyway, why bother doing extra work to keep one 
> particular application that occupies a small fraction of the remaining 
> 15% running? (I.e., with unlike with IPv4, with IPv6, TCP and UDP have 
> the same failure mode in the presence of PMTUD black holes. And if 
> depending on PMTUD is too deemed dangerous, then 1280 is the answer, with 
> no need for any testing.)

Actually the don't have the same failure modes.

For UDP you send DNS request to a anycast cluster and you hits
server A.  It gets the PTB response which the kernel records but
the DNS server can't do anything with it as the transaction state
is gone.

The client times out and sends a second UDP DNS request.  This hits
server B.

The client times out and sends a third UDP DNS request.  This hits
server C.

The client times out and sends a fourth UDP DNS request.  This hits
server A which may or may not still remember the PMTU from the PTB.

For TCP the PTB should go to server A and TCP transaction should
resume.  If the PTB gets lost / misdirected then by the time server
A notices it is too late.  The client has given up.

Add multiple drops in MTU along the path and it gets worse.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 Jun 2015 13:28:01 +0200

Le 22/06/2015 22:50, Owen DeLong a écrit :
>> Well, one cellular network operator has a /47 to 'share' with all
>> its customer UEs.  If that operator gave a /48 to an UE it could
>> satisfy only 2 such customers, not millions.
>
> We should not be designing around providers that didn’t ask for
> enough IPv6 space for their deployments. We should educate those
> providers. IPv6 space is easy to get. A cellular network is an ISP
> almost by definition.
>
> There isn’t a single RIR on the planet that won’t grant you at least
> a /32 if you walk up and say “I’m an ISP, /32 please” in any credible
> way.
>

So I looked at the RIR database.

The RIR already allocated a /19 to that operator.  But the operator 
fitted all its end users within a /47 (each getting a /64.)

The operator should fit all its end users within a /39 (not a /47), and 
each end user must get a /63.  At least.

Is RIR to be questioned when the operator delivers only /64s to end 
users?  Or the operator?

>>> but at least provide enough subnets to cover BT, USB, 2.4, and
>>> 5Ghz plus some headroom for future applications.
>>
>>>>> *) Internet Sharing on the Mac Today, regular internet
>>>>> sharing (from your ethernet to Wi-Fi for example) does not
>>>> If you get done the above then you get Internet Sharing on the
>>>> Mac Today as well, for free.
>>>

Right.  I meant it's not an app supposed to work on both families.  It 
is pure v6.

[...]

Alex

---

From: David Schinazi <[email-masked]>
Date: Wed, 24 Jun 2015 00:15:44 -0700

Hi again,

First off, thanks everyone for the feedback and advice!
Here's an attempt at answering the questions that arose since my last post.

*) Personal hotspot on iOS
Currently the hotspot shares whatever address families it gets from the cellular network.
The current implementation broadcasts an IPv6-only network if the cellular network is of that type,
but I could imagine carriers bringing up IPv4 specifically when using this feature. Our custom version
of prefix sharing is described in more detail here:
https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prproxy.c <https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prproxy.c>
It supports creating multiple hotspots at the same time, such as Wi-FI and Bluetooth and bridges them.

*) iOS and cellular carrier networks
I do not know if or when specific carriers plan to change their IPv6 policies. That said, we do believe
there is a growing trend towards IPv6. When roaming between carriers, your device will get new
addresses and could possibly switch between address families.

*) VPN
Our implementation of IKEv2, which is our current recommended VPN protocol, supports IPv6 on both
the inside and outside of the tunnel. Other protocols are currently not guaranteed to be fully compatible.

*) Internet Sharing on the Mac
We agree that it would be nice to support IPv6, but the risk/reward tradeoff isn't necessarily there yet.

*) Internet Sharing on the Mac - NAT64 testing mode
To reset expectations on this feature, it targets developers of networked apps that are not knowledgeable
in IPv6, most likely not anyone on this list. If you're writing your own sockets code that works on dual-stack
and have a dual-stacked server, you probably know what you're doing already. The goal is really not
performance optimization, simply checking that your app will manage to connect to your server at all.
Realistically, today any service accessible by apps over IPv6 is also available over IPv4. Debugging path
MTU issues is currently out of scope of this test network. The App Store IPv6 compatibility requirement will
not reject an app solely based on tests using the NAT64 test network. The NAT64+DNS64 on the Mac will
currently only query for A records and return synthesized AAAA records to its clients, it effectively ignores any
AAAA records it receives from the wide area. We're looking into improving this feature, we agree that adding
real IPv6 connectivity and using a different prefix would be better.

*) Happy Eyeballs
Thanks to everyone for the advice on this topic, we're looking into the best compromise between providing
our customers with good response times in the short term and helping them in the long term by helping the
deployment of IPv6. An issue with RFC 6555 is that it was designed in a mindset where DNS resolution is
provided by synchronous APIs such as getaddrinfo. In practice, your AAAA and A records do not come back
at the same time and if you receive the A record first, every millisecond you wait before sending out a SYN is
an IPv6 tax you're levying on your users. This being helpful in the long term, there must be a sweet spot. To
clarify our use of the RTT to prioritize addresses, we use historical RTT measurements of all TCP packets on
that route. If and when we release an updated implementation, I will update this list.

*) 464XLAT
We've considered using this technology and decided that it was not the best course of action. This doesn't
mean we will never consider it and we're definitely interested in discussing pros and cons but in my
humble (personal) opinion, calling us names to "get our attention" is not likely to convince us that 464XLAT
is the One True Path to IPv6 deployment.

As mentioned in my last message, all these details only reflect the current betas and can change in the future.

Thanks,
David

> On Jun 19, 2015, at 14:46, David Schinazi <[email-masked]> wrote:
> 
> Hi everyone,
>

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 24 Jun 2015 00:52:52 -0700

> The few tcpdump logs I’ve looked at would seem to indicate that most (including Apple’s) HE implementations I’ve encountered do the former rather than the latter. Also as near as I can tell, state…

Best explanation of Apple's implementation is by Josh Graessley, who designed (and I believe also coded) the algorithm, http://lists.apple.com/archives/ipv6-dev/2011/Jul/msg00009.html.  Things have probably improved since 2011.

-d

---

From: "Heatley, Nick" <[email-masked]>
Date: Wed, 24 Jun 2015 07:58:11 +0000

From: v6ops [mailto:[email-masked]] On Behalf Of David Schinazi
Sent: 24 June 2015 08:16
To: [email-masked]
Cc: Vividh Siddha
Subject: Re: [v6ops] Apple and IPv6, a few clarifications

Hi again,

https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prproxy.c

[Heatley, Nick] Thanks for sharing the information, David.
When you say you imagine carries bringing up IPv4 specifically for personal hotspot, not sure what you mean - do you mean a parallel, dedicated "hotspot APN"?
Many carriers across the globe, for their own individual business reasons, have a common APN approach for the mass consumer market, but nevertheless desire this common APN to go IPv6-only.

So I am nervous about how to support *any* device on a personal hotspot from an IPv6-only iOS handset in this way, do you have any more details on your intentions here?
Thanks for the discussion. Nick

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: 🔓Dan Wing <[email-masked]>
Date: Wed, 24 Jun 2015 01:08:06 -0700

> that route. If and when we release an updated implementation, I will update this list.

I have long thought Apple's implementation of Happy Eyeballs is awesome.  Tweaking the algorithm's built-in fudge factor to trend more towards IPv6 would make it more consistent with other OSs and applications (which give 200-300ms Happy Eyeballs head start to IPv6, which is similar to the fudge factor done by Apple).  Myself, I would like the fudge factor to be configurable via sysctl or at least viewable via netstat (or similar).  As it is, it is difficult to understand why a system is heavily preferring IPv4 or IPv6, and when it will give up; disconnecting and reconnecting the network is a harsh troubleshooting step for other traffic.

-d

>> On Jun 19, 2015, at 14:46, David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi everyone,
>>

---

From: Erik Kline <[email-masked]>
Date: Wed, 24 Jun 2015 17:57:37 +0900

On Mon, Jun 22, 2015 at 9:16 PM, Mikael Abrahamsson <[email-masked]> wrote:
> DHCPv6-PD exists in recent 3GPP documents, but vendor implementation of this
> is not wide-spread. We do *not* want to gate IPv6 rollout in mobile networks
> on this functionality. Yes, we want it, but we can't wait for it.

(off-topic: So, are you saying that DT is most definitely not blocked
on DHCPv6-PD as far as enabling IPv6 on LTE is concerned?)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Jun 2015 11:41:11 +0200 (CEST)

On Wed, 24 Jun 2015, Erik Kline wrote:

>> this is not wide-spread. We do *not* want to gate IPv6 rollout in 
>> mobile networks on this functionality. Yes, we want it, but we can't 
>> wait for it.
>

Re-reading my sentence above I agree it can be interpreted as me speaking 
for DT as whole. That was not my intention. I have no recent information 
as to what the current state of IPv6 rollout is in DT Germany mobile 
network.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jun 2015 12:38:21 +0200

Le 24/06/2015 11:41, Mikael Abrahamsson a écrit :
>>> DHCPv6-PD exists in recent 3GPP documents, but vendor implementation
>>> of this is not wide-spread. We do *not* want to gate IPv6 rollout in
> Re-reading my sentence above I agree it can be interpreted as me
> speaking for DT as whole. That was not my intention. I have no recent
> information as to what the current state of IPv6 rollout is in DT
> Germany mobile network.
>

DHCPv6-PD in recent 3GPP documents is between entities within the core 
network.  The 3GPP specs dont tell DHCPv6 Prefix Delegation towards the 
UE.  The UE in 3GPP specs does not implement DHCPv6 PD.

What is the status of DT IPv6 trials - do they exist?

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Jun 2015 13:38:42 +0200 (CEST)

> UE. The UE in 3GPP specs does not implement DHCPv6 PD.

You are mistaken.

http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/12.06.00_60/ts_123401v120600p.pdf

Section 5.3.1.2.6.

DHCPv6-PD towards the UE came into the 3GPP standards at least 3 years 
ago. Mobile core networks that implement this is another matter.

---

From: Ca By <[email-masked]>
Date: Wed, 24 Jun 2015 05:13:31 -0700

On Wednesday, June 24, 2015, Erik Kline <[email-masked]> wrote:

> On Mon, Jun 22, 2015 at 9:16 PM, Mikael Abrahamsson <[email-masked]
> <javascript:;>> wrote:
> this
Erik,

Probably chicken and eggs with a side of  customers dont care.

Does Android suppot dhcp-pd ?

CB

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jun 2015 14:38:13 +0200

Le 24/06/2015 13:38, Mikael Abrahamsson a écrit :
>> DHCPv6-PD in recent 3GPP documents is between entities within the
>> core network.  The 3GPP specs dont tell DHCPv6 Prefix Delegation
>> towards the UE. The UE in 3GPP specs does not implement DHCPv6 PD.
>
> You are mistaken.
>

Ok, thanks for the pointer.

I checked that section and indeed it is specifying DHCPv6-PD towards the 
UE.  That is encouraging.

> DHCPv6-PD towards the UE came into the 3GPP standards at least 3
> years ago.

I didnt know that.

This document version is dated September 2014.

> Mobile core networks that implement this is another matter.

How long would it take to see it on operator networks?

Because my UEs are ready to issue these DHCPv6 Prefix Delegation requests.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jun 2015 14:39:13 +0200

Le 24/06/2015 14:13, Ca By a écrit :
>
>
> On Wednesday, June 24, 2015, Erik Kline <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Jun 22, 2015 at 9:16 PM, Mikael Abrahamsson
>     <[email-masked] <javascript:;>> wrote:
>     smartphones (not a
>     implementation of this

Android is a linux based os, I dont see why it wouldnt support dhcp-pd?

My linux based non-Android machines do dhcp-pd ok.

Alex

---

From: Ross Chandler <[email-masked]>
Date: Wed, 24 Jun 2015 13:52:49 +0100

> On 22 Jun 2015, at 23:58, Ca By <[email-masked]> wrote:
> 
> For some subset of networks, devs can test the real production deal if apple could surface the apn setting in dev builds. It is hard to see the harm in this. Other OSs allow apn setting fiddling. Also, this allows an escape hatch for the inevitable user who cannot deal with ipv6-only in production... And opens the door for end user opt in trials of ipv6. 
> 
> It's really not a hard problem to solve for many situations (like tmus)  but the some backwards place .... They may not have this luxury of proper ipv6 in mobile :/
> 
> CB 

+1

At lot of people that could help with IPv6-only deployment lose interest when they hear that they have to have an Android or Windows Phone to try it.

Ross

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jun 2015 16:12:19 +0200

Hi, thanks for the reply.

Le 24/06/2015 09:15, David Schinazi a écrit :
> Hi again,
>
> First off, thanks everyone for the feedback and advice! Here's an
> attempt at answering the questions that arose since my last post.
>
> *) Personal hotspot on iOS Currently the hotspot shares whatever
> address families it gets from the cellular network. The current
> implementation broadcasts an IPv6-only network if the cellular
> network is of that type, but I could imagine carriers bringing up
> IPv4 specifically when using this feature. Our custom version of
> prefix sharing is described in more detail here:

I looked at the file. It does proxy Neighbor Discovery in order to
bridge. Proxy ND is an EXPERIMENTAL RFC4389. 64share is an
INFORMATIONAL RFC7278. This means they are not the perfect way to aim
for interoperability. An Apple smartphone could not talk to a GM car
(just examples of brand names).

In the car use-case the smartphone connects to the dashboard using a ptp
link.  And it's the car's dashboard which offers a WiFi hotspot.  These
couldn't be bridged (ND proxy) by the smartphone alone, it would need
the dashboard router to participate in this ND proxy.

What the smartphone needs is to route with longest-prefix matching and 
use different prefixes on each interface.  That is an interoperable way 
to connecting different subnets, and the RFCs are typically on the Stds 
Track (not INFORMATIONAL, nor EXPERIMENTAL).

Isn't the car use-case important for Apple smartphones?

(I mention car use-case because I work on these these days, but the
discussion of ND proxy is much older and it originated in a home context
with cable ISP and IPv6).

> Wi-FI and Bluetooth and bridges them.

But insecurely.  Bluetooth and WiFi have different security mechanisms.
  The security mechanisms wouldn't bridge.

> *) iOS and cellular carrier networks I do not know if or when
> specific carriers plan to change their IPv6 policies. That said, we
> do believe there is a growing trend towards IPv6. When roaming
> between carriers, your device will get new addresses and could
> possibly switch between address families.

I agree.

Alex

>
> *) VPN Our implementation of IKEv2, which is our current recommended
>  VPN protocol, supports IPv6 on both the inside and outside of the
> tunnel. Other protocols are currently not guaranteed to be fully
> compatible.
>
> *) Internet Sharing on the Mac We agree that it would be nice to
> support IPv6, but the risk/reward tradeoff isn't necessarily there
> yet.
>
> *) Internet Sharing on the Mac - NAT64 testing mode To reset
> expectations on this feature, it targets developers of networked apps
> that are not knowledgeable in IPv6, most likely not anyone on this
> list. If you're writing your own sockets code that works on
> dual-stack and have a dual-stacked server, you probably know what
> you're doing already. The goal is really not performance
> optimization, simply checking that your app will manage to connect to
> your server at all. Realistically, today any service accessible by
> apps over IPv6 is also available over IPv4. Debugging path MTU issues
> is currently out of scope of this test network. The App Store IPv6
> compatibility requirement will not reject an app solely based on
> tests using the NAT64 test network. The NAT64+DNS64 on the Mac will
> currently only query for A records and return synthesized AAAA
> records to its clients, it effectively ignores any AAAA records it
> receives from the wide area. We're looking into improving this
> feature, we agree that adding real IPv6 connectivity and using a
> different prefix would be better.
>
> *) Happy Eyeballs Thanks to everyone for the advice on this topic,
> we're looking into the best compromise between providing our
> customers with good response times in the short term and helping them
> in the long term by helping the deployment of IPv6. An issue with RFC
> 6555 is that it was designed in a mindset where DNS resolution is
> provided by synchronous APIs such as getaddrinfo. In practice, your
> AAAA and A records do not come back at the same time and if you
> receive the A record first, every millisecond you wait before sending
> out a SYN is an IPv6 tax you're levying on your users. This being
> helpful in the long term, there must be a sweet spot. To clarify our
> use of the RTT to prioritize addresses, we use historical RTT
> measurements of all TCP packets on that route. If and when we release
> an updated implementation, I will update this list.
>
> *) 464XLAT We've considered using this technology and decided that it
> was not the best course of action. This doesn't mean we will never
> consider it and we're definitely interested in discussing pros and
> cons but in my humble (personal) opinion, calling us names to "get
> our attention" is not likely to convince us that 464XLAT is the One
> True Path to IPv6 deployment.
>
> As mentioned in my last message, all these details only reflect the
> current betas and can change in the future.
>
> Thanks, David
>
>
>> I'd like to clarify a few points about Apple's IPv6 announcements
>> during WWDC 2015. The video (streaming with Safari or download with
>> all browsers) and slides of that talk are available at:
>> https://developer.apple.com/videos/wwdc/2015/?id=719
>>
>> connectivity on its cellular network, the hotspot it creates will
>> be dual-stack as well. The phone will share its prefix with Wi-Fi
>> clients.
>>
>>  mode was designed to help developers ensure that their app can
>> still function with IPv6-only NAT64+DNS64 connectivity and
>>  IPv6 connectivity to the global IPv6 internet. As such, the
>> current version advertises addresses from 2001::/64 instead of ULAs
>> to simulate real IPv6 connectivity, as all IPv6 packets are
>> terminated at the NAT64 server on the Mac. This implementation
>> detail could change in the future.
>>
>>  future betas. Please keep in mind that these betas are previews
>> and we welcome feedback on improving them.
>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Jun 2015 23:34:52 +0900

> Does Android suppot dhcp-pd ?

:-)

---

From: Gert Doering <[email-masked]>
Date: Wed, 24 Jun 2015 17:10:15 +0200

Hi,

> (just examples of brand names).

Crap.  The devices on either sides will not see which method the device
in the middle deploys to achieve reachability.

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jun 2015 17:26:39 +0200

> in the middle deploys to achieve reachability.

Crap?  The smartphone doing ND proxy is useless if the car's router is 
not doing the same.  And currently car routers dont do ND proxy.

      ----------                ---------                         ------
4G--|smartphone|-----BT-------|CarRouter|------hotspotWiFi------|tablet|
      ----------                ---------                         ------

Alex

---

From: Gert Doering <[email-masked]>
Date: Wed, 24 Jun 2015 18:18:58 +0200

Hi,

> not doing the same.  And currently car routers dont do ND proxy.

Crap.

So?  What "smartphone" does is of no interest to "CarRouter".  It

 ** WILL **
 ** NOT **
 ** SEE **

which method "smartphone" deploys to achieve reachability.

Gert Doering
        -- NetMaster

---

From: james woodyatt <[email-masked]>
Date: Wed, 24 Jun 2015 11:27:31 -0700

On Jun 24, 2015, at 05:52, Ross Chandler <[email-masked]> wrote:
>> On 22 Jun 2015, at 23:58, Ca By <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Another aggravation regarding IPv6-only APNs on iOS is that an unlocked iPhone is unable to use an IPv6-only APN. The only way in iOS to control the type of the APN is with a provisioning profile, and these are not used on unlocked phones. Maybe one of the carriers with sufficient influence with Apple Core OS Engineering that their demands have some hope of sticking could complain to them about this? It’s the reason I can’t use IPv6 APNs when I’m traveling on a foreign SIM card. I know, I know, like there is such a carrier who has any interest in seeing unlocked phones have any more useful features.

—james

---

From: james woodyatt <[email-masked]>
Date: Wed, 24 Jun 2015 11:38:06 -0700

On Jun 24, 2015, at 07:12, Alexandru Petrescu <[email-masked]> wrote:
> 
> […] In the car use-case the smartphone connects to the dashboard using a ptp
> the dashboard router to participate in this ND proxy. […]

I suspect the point you may be missing here is the logic encoded elsewhere in iOS that restricts the use of Mobile Internet Sharing to the telephony uplink. It is not possible with iOS to share Internet access over the Wi-fi (or other interfaces) with tethered devices. Only the telephony data service is eligible for Mobile Internet Sharing.

Shorter james: the automotive Wi-fi hotspot use case is like every other Wi-fi hotspot as far as iOS is concerned, i.e. every phone on Wi-fi is an ordinary host and not a ND proxy or a router.

—james

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Jun 2015 09:41:29 +1000

> which method "smartphone" deploys to achieve reachability.

If the smart phones in doing ND proxy then there is no PD therefore
the hotspotWiFi won't have a GUA prefix.

This we will kludge cellphones instead of just doing it right in
the first place is coming back to bite us.

> --=20

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 25 Jun 2015 04:59:02 +0200 (CEST)

On Wed, 24 Jun 2015, james woodyatt wrote:

> Another aggravation regarding IPv6-only APNs on iOS is that an unlocked 
> iPhone is unable to use an IPv6-only APN. The only way in iOS to control 
> the type of the APN is with a provisioning profile, and these are not 
> used on unlocked phones.

I don't know what you mean by "provisioning profile", but my wifes 
unlocked iPhone6+ received an update to her carrier profile with iOS 8.3 
and it used the IPv4v6 APN just fine without any kind of user 
intervention.

> influence with Apple Core OS Engineering that their demands have some 
> hope of sticking could complain to them about this? It’s the reason I 
> can’t use IPv6 APNs when I’m traveling on a foreign SIM card. I know, I 
> know, like there is such a carrier who has any interest in seeing 
> unlocked phones have any more useful features.

Well, the major thing here is Apple controls and approves the profile, not 
the carrier. There are plenty of carriers who are interested but who have 
to convince Apple to get changes done.

---

From: Gert Doering <[email-masked]>
Date: Thu, 25 Jun 2015 09:13:35 +0200

Hi,

> the first place is coming back to bite us.

Smartphones can do PD all they want - if the mobile operator isn't
*offering* PD, there's not very much they can do.  "Offer no IPv6 for
tethered clients" or "do proxy ND / bridge the /64".

Pick your poison.

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jun 2015 10:59:39 +0200

Le 25/06/2015 09:13, Gert Doering a écrit :
>> If the smart phones in doing ND proxy then there is no PD
>> therefore the hotspotWiFi won't have a GUA prefix.
>>
> *offering* PD, there's not very much they can do.

After reading Mikael's email pointing to a 3gpp spec of late 2014
mandating DHCPv6-PD to both UE and core network - I must say I am
optimistic about the arrival of DHCPv6-PD to cellular network operators.

Currently, some cellular networks already offer DHCPv6 together with
SLAAC.  Technically that DHCPv6 is extremely simple to upgrade to DHCPv6-PD.

My question is when?

I can speculate it will be in late 2016.  Because 4G was in specs 2
years before trial deployments.

> "Offer no IPv6 for tethered clients" or "do proxy ND / bridge the
> /64".
>
> Pick your poison.

Good if it were that simple.  But I am afraid there's a 3rd choice more 
poisonous than you present.

Alex

>
> Gert Doering -- NetMaster
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jun 2015 11:11:11 +0200

Le 24/06/2015 20:38, james woodyatt a écrit :
> On Jun 24, 2015, at 07:12, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>>
>> […] In the car use-case the smartphone connects to the dashboard
>> using a ptp link.  And it's the car's dashboard which offers a
>> WiFi hotspot.  These couldn't be bridged (ND proxy) by the
>> smartphone alone, it would need the dashboard router to participate
>> in this ND proxy. […]
>
> I suspect the point you may be missing here is the logic encoded
> elsewhere in iOS that restricts the use of Mobile Internet Sharing
> to the telephony uplink. It is not possible with iOS to share
> Internet access over the Wi-fi (or other interfaces) with tethered
> devices. Only the telephony data service is eligible for Mobile
> Internet Sharing.

That is a good point.

There is an ongoing technical debate in the car comm community - should
the smartphone provide Internet connectivity to the car?  Or should the
smartphone use the Internet connectivity offered by the car.

Right now where I live a large number of marketed cars are on the first
option.  It is on that option that I think smartphone's iOS Mobile
Internet Sharing can help, provided it does more than NDproxy.

> Shorter james: the automotive Wi-fi hotspot use case is like every
> other Wi-fi hotspot as far as iOS is concerned, i.e. every phone on
> Wi-fi is an ordinary host and not a ND proxy or a router.

Well I did not mean the smartphones using car's hotspots.  That's for
WiFi-only tablets.

The NDproxy problem in iOS is in the case where cars create hotspots by
their own means, but disconnected from the Internet.  All they need is
to reach the Internet somehow without having to put a SIMcard in the
car.  And that's where cars connect to the smartphone with Bluetooth.
(cars already connect to smartphone with bluetooth for Audio-Video
screen replication and phone calls (although phone calls are going to be
completely forbidden soon even for handsfree)).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jun 2015 11:13:59 +0200

I agree.

We have already seen this with cable boxes at home: the first IPv6 cable 
boxes ten years ago were also doing ND proxy.  Not any longer - the 
now-classic home boxes have several /64s to deliver how they like to the 
home's subnets.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jun 2015 11:15:15 +0200

> which method "smartphone" deploys to achieve reachability.

That's why the CarRouters are pure routers and dont do NDproxy.

And that's why CarRouters need the smartphones to provide them DHCPv6 
Prefix Delegation in return.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 25 Jun 2015 11:28:48 +0200 (CEST)

> years before trial deployments.

To repeat myself:

DHCPv6-PD requirement didn't appear in 2014.

http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/10.03.00_60/ts_123401v100300p.pdf 
from 2011-MARCH contains prefix delegation, and since it's not available 
in release 9, it seems this is indeed a LTE release 10 feature that is 
more than 4 years old, and still there isn't widespread implementation of 
it that I am aware of.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jun 2015 11:54:50 +0200

Le 25/06/2015 11:28, Mikael Abrahamsson a écrit :
> more than 4 years old, and still there isn't widespread implementation
> of it that I am aware of.

This makes either the specs irrelevant or the products on the market 
non-conformant.

An UE implements DHCPv6-PD and the core network does not reply to PD 
requests although it replies to DHCPv6 address requests) is a violation 
of specification.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 25 Jun 2015 10:57:48 +0100

On 25/06/2015 10:54, Alexandru Petrescu wrote:
> requests although it replies to DHCPv6 address requests) is a violation of
> specification.

Do you have names and addresses and we'll set the protocol police on the
immediately?

Nick

---

From: Gert Doering <[email-masked]>
Date: Thu, 25 Jun 2015 13:02:13 +0200

Hi,

> This makes either the specs irrelevant or the products on the market 

Good morning.  So you finally start seeing the light.

3G mandated(!) IPv6 over 10 years ago.  Conclusions left as homework for 
the interested reader.

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jun 2015 13:21:40 +0200

Le 25/06/2015 11:57, Nick Hilliard a écrit :
>> An UE implements DHCPv6-PD and the core network does not reply to
>> PD requests although it replies to DHCPv6 address requests) is a
>> violation of specification.
>
> Do you have names and addresses and we'll set the protocol police on
> the immediately?

:-) ok police is about human behaviour.

But specs (especially 3gpp specs) are spread throughout procurement
contracts. If these specifications can not be trusted then all clauses
break. One doesnt like to pay amount but get less.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jun 2015 13:28:23 +0200

Le 25/06/2015 13:02, Gert Doering a écrit :
>> This makes either the specs irrelevant or the products on the
>> market non-conformant.
>
> 3G mandated(!) IPv6 over 10 years ago.  Conclusions left as homework
> for the interested reader.

The interested reader should look at the evolution too.  When IPv6/3gpp
was mandated there was no operator offering IPv6 - the only method to
have IPv6 on a cellular link was to tunnel through IPv4.  Then came one
or two operators in northern Europe proposing IPv6 for trials on
cellular.  Today there are several cellular operators offering native
IPv6 to the public, and some trials.  Some even propose IPv6-only (i.e.
no IPv4).

But IPv6 is a large replacement.

DHCPv6-PD is just a simple upgrade to DHCPv6-for-addresses.

That's why I think it would be less than 2 years before we see DHCPv6-PD
at the cellular operator.

Alex

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 25 Jun 2015 09:59:12 -0700

> of it that I am aware of.

Yes, we put PD into Rel-10 around mid/late 2010. The CRs to 23.060 and 
23.401 that then added prefix exclusion (RFC6603) were in Nov 2010.

- Jouni

---

From: james woodyatt <[email-masked]>
Date: Thu, 25 Jun 2015 10:35:01 -0700

On Jun 24, 2015, at 19:59, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I don't know what you mean by "provisioning profile", but my wifes unlocked iPhone6+ received an update to her carrier profile with iOS 8.3 and it used the IPv4v6 APN just fine without any kind of user intervention.

Yes, I forgot. The carrier profile can do this too. Either way, there isn’t a way for an ordinary user with an unlocked phone to pick the APN type on whatever service they are using. Apple and the carrier must conspire to make IPv6 happen automatically or it doesn’t happen. Because Core Telephony. Grumble grumble grumble.

—james

---

From: james woodyatt <[email-masked]>
Date: Thu, 25 Jun 2015 10:45:01 -0700

On Jun 25, 2015, at 02:15, Alexandru Petrescu <[email-masked]> wrote:
> And that's why CarRouters need the smartphones to provide them DHCPv6 Prefix Delegation in return.

Hierarchical prefix delegation. (Again. What a great idea. Face palm.) I think what Mr. Petrescu meant to say is that CarRouters need smartphones to offer HNCP services. Who will be brave enough to set that standard?

—james here

---

From: Gert Doering <[email-masked]>
Date: Thu, 25 Jun 2015 20:30:57 +0200

Hi,

On Thu, Jun 25, 2015 at 01:28:23PM +0200, Alexandru Petrescu wrote:
> have IPv6 on a cellular link was to tunnel through IPv4.  

Of course there was no operator before it was mandated in the standard - 
didn't stop the operators from still not offering *when* it was.

(As for upstream connectivity: ISPs were offering commercial IPv6 service
15 years ago already - not all of them, but if you *wanted*, you could
get it.  So that's all a very lame excuse to just ignoring the mandatory
bit of the standard for 10+ years)

Gert Doering
        -- NetMaster

---

From: Jared Mauch <[email-masked]>
Date: Thu, 25 Jun 2015 14:45:10 -0400

> On Jun 25, 2015, at 1:35 PM, james woodyatt <[email-masked]> wrote:
> 

Yes, this is something I saw with Verizon and my iPad, I was getting IPv6 then some carrier update made it go away and it’s not come back since.

I just got a USA T-Mobile SIM and it does IPv6 properly in a $30 GSM/LTE <-> WIFI and I can get v6 on any device connected.

Quite a stark difference in “does it right” vs “does it wrong”.

I periodically have issues with comcast changing my prefix and hosts not picking them up right, but that’s a bit harder to trace as it happens so infrequently.

- jared

---

From: Gert Doering <[email-masked]>
Date: Thu, 25 Jun 2015 21:01:49 +0200

Hi,

> I just got a USA T-Mobile SIM and it does IPv6 properly in a $30 GSM/LTE <-> WIFI and I can get v6 on any device connected.

What device are you using for this?  "Mobile 3G/Wifi router thingies" 
that support IPv6 are not exactly easy to find on the market, let alone 
"properly!"...

(Have a TP-Link M5350 here which is a very very nice 3G/Wifi thingie,
but alas, no v6 and no plans to ever support it "because nobody is using
IPv6 on 3G" - yes, that's why, thanksverymuch)

gert

---

From: Owen DeLong <[email-masked]>
Date: Thu, 25 Jun 2015 12:08:14 -0700

> On Jun 25, 2015, at 02:11 , Alexandru Petrescu <[email-masked]> wrote:
> 
> 
> 

The car community should not be making this decision.

The car _AND_ the smartphone should be delivered in such a way that the
end user can choose whichever plan best suits his needs and offers him the
best set of tradeoffs between features, price, and whatever else the end user
chooses to care about.

If I want the phone to provide the connectivity to the car, I should be able
to do that.

If I want the car to provide connectivity and have the phone use that, I should
be able to do that.

I should be able to choose and I should be able to change my decision whenever
it suits me.

> Internet Sharing can help, provided it does more than NDproxy.

For most of the marketed cars I am aware of in the US where that is the
case, it is largely because the car doesn’t really know what a network is
in any meaningful way, or, because the car maker didn’t want to think about
solving the connectivity problem in a useful way.

I do not know of a case where it is a well thought out decision by the
manufacturer to have that as a deliberate architecture rather than just
laziness at best.

Owen

---

From: Gert Doering <[email-masked]>
Date: Thu, 25 Jun 2015 21:14:28 +0200

Hi,

> I should be able to choose and I should be able to change my decision whenever

No.

For *you* this might make sense and be a useful feature.  For me, I might
like it, but will never actually use it (because I'm way too lazy to be
interested in multiple possible Internet uplinks for my car - and why I
should bother to trade the nice *external* antenna of the car with the
great reception of a typical smartphone inside a large moving metal box).

For the typical driver who is already challenged pairing his mobile via
BT with his car's handsfree?  No go.  Do one thing, do it well, and NEVER
ask a car owner (or any normal Internet user) about technical decisions.

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Thu, 25 Jun 2015 12:24:47 -0700

> ask a car owner (or any normal Internet user) about technical decisions.

We can agree to disagree. IMHO, this should be as simple as two settings.

One on the phone: Provide Internet Access to Car: ON/OFF

One in the car: Get internet access from: CAR <-> PHONE

As to the typical driver being challenged pairing his mobile, frankly, I’m challenged
with that on many occasions, not because I don’t know how to do it and not because
I don’t understand what is involved or can’t follow directions, but because BlueTooth
pairing implementation on most cars and most devices is a steaming pile of poorly
written and even less well tested code that is fragile, buggy, and unreliable.

Assuming that the underlying connectivity code works, the above two settings
should not be difficult to implement correctly. They are far less complex than
Bluetooth.

Owen

---

From: Jared Mauch <[email-masked]>
Date: Thu, 25 Jun 2015 15:55:07 -0400

> IPv6 on 3G" - yes, that's why, thanksverymuch)

	Ok since more than one person asked me:

	ZTE MF96 4G LTE Wireless Mobile Hotspot Router Sonic

http://www.ebay.com/itm/ZTE-MF96-4G-LTE-Wireless-Mobile-Hotspot-Router-Sonic-2-0-WiFi-T-Mobile-USB/181704373447

	with this sim card:

	https://www.sparkfun.com/products/13186

	The one I received had an OTA software update available
and I applied it.  Don't know if that was required to make it work for v6
but being an avid software beta tester, i always update firmware.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 26 Jun 2015 06:48:01 +0000 (UTC)

From: Owen DeLong <[email-masked]>
 To: Gert Doering <[email-masked]> 
Cc: [email-masked] 
 Sent: Friday, 26 June 2015, 5:24
 Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots

/ I think another thing to remember is that "enablement" can imply a default. For example, if my car comes with a SIM slot, and I choose to put one on in it, then I've implicitly chosen that the car should by default use the connectivity provided by its own 3/4G connectivity. I'm also have likely to have chosen the particular SIM and its associated usage plan based on my expected usage of the Internet by and possibly in the car. If the car also has a Wifi hotspot in it, I'll likely associate my phone with it once, so that from then on my phone will automatically use the car's connectivity every time I get in it, without any intervention on my part at all. That would be much more convenient than having to switch on and off hotspot support on my phone each and every time I get in the car - and it is likely people will sometimes forget, and then try to do that while they're driving, which will be as or more dangerous than sending text messages while driving.
/ Having choice can be good, but you want to try to minimise both the amount of choices and how often people have to make them - too much choice can lead to paralysis, such that making no choice becomes the safest "choice".  I think when it comes to usability, predictable and expected defaults, and matching peoples' existing conceptual and mental models are much better. The book "The Design of Every Day Things" is an excellent book on making things easier to use.
/ Regards,/ Mark.

Owen

---

From: Philip Homburg <[email-masked]>
Date: Fri, 26 Jun 2015 11:20:05 +0200

>great reception of a typical smartphone inside a large moving metal box).

I hope that car manufacturers will find their way back into modular electronics,
just like car radios ages ago.

With he current rate of development, car electronics are obsolete for most of
the car's lifetime.

A good example is built-in navigation systems, where car manufactures have a
hard time understanding what to charge for updating maps, so people just use
a standalone device next to the built-in one.

Android devices typically receive their last update 1.5 years after the devices
were last sold. Nice driving around with an unpatched, internet connected
car entertainment system.

With modular electronics, those who want their pi powered hadoop cluster can
just by an aftermarket upgrade.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 26 Jun 2015 07:11:26 -0700

> On Jun 25, 2015, at 23:48 , Mark ZZZ Smith <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> From: Owen DeLong <[email-masked] <mailto:[email-masked]>>
> To: Gert Doering <[email-masked] <mailto:[email-masked]>> 
> Cc: [email-masked] <mailto:[email-masked]> 

I’m all for intelligent defaults in the settings in question, but I want the ability to make those choices without having to plug/unplug hardware.

Cars are mobile. Phones are mobile. Carrier policies less so. It may well be that I have different phones for different localities. When I’m home, I want to use the SIM I put in the car. When I drive somewhere else I may well want to switch off of using that SIM onto using a phone which I maintain for that locality. I don’t want to have to make hardware changes to facilitate this.

Until you can get carriers to offer reasonable roaming prices (along the lines of current T-Mo free international data or better), these kinds of needs will persist.

If you want examples of just how bad this is, single-SIM phones are the exception rather than the rule if you shop for a phone in Hong Kong. Most have dual-SIM capability and some even take 3 last I looked.

I don’t hold T-Mo up as any sort of shining example in general, but their pricing plan is the one and only one reason I’m using them for now. Other carriers should take note of this if they want my business.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Jun 2015 17:01:08 +0200

> best set of tradeoffs between features, price, and whatever else the end user

This is a great formulation of requirements but there is nothing else 
outside the car industry that did this kind of behaviour in the past. 
So it's not that easy to implement.  (typically a automated 
configuration is using RA/DHCP/NAT and these have a strong notion of 
directivity - client and server, provider and consumer; in the car 
setting you have two strongly opposed interests smartphone's and car's).

You dont have one protocol that can change roles dynamically.  A DHCP 
Server is a Server can't dynamically become a Client.  A NAT is in one 
direction cant dynamically change direction.

Worse - Internet addresses are centrally assigned and distributed, one 
can't make IP addresses out of nothing and reach the Internet 
bidirectionally.

That's why it's easier if a decision were made (one of the two provides 
Internet to the other).

> I should be able to choose and I should be able to change my decision whenever

This is very strong requirements and difficult to meet.

> manufacturer to have that as a deliberate architecture rather than just

I wouldnt say laziness, some work hard at it, but it's not easy.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Jun 2015 17:05:02 +0200

> great reception of a typical smartphone inside a large moving metal box).

Well recent 5-way extra-small antennas are getting better signal if 
sitting on roof rather than on the smartphone.  BEsides, they catch not 
only 4G but also GPS and 802.11p.

The reception of a typical smartphone inside the car is great some 
times, but less so other times.  If just some little browsing then 
reception is not a problem.  But a 24/7 audio/video stream is improved 
by better antennas in certain areas and with thermally-thick windows.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Jun 2015 17:07:08 +0200

> One in the car: Get internet access from: CAR <-> PHONE

Except that one wants the car to get Internet access from the 
passenger's smartphone, and other times from in-house hotspot, from the 
PLC-enabled-charging-station at home, from the WiFi or 802.11p hotspots 
in some areas like Parking or gas station.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Jun 2015 17:10:55 +0200

Le 26/06/2015 08:48, Mark ZZZ Smith a écrit :
>
> ------------------------------------------------------------------------
> *From:* Owen DeLong <[email-masked]>
> *To:* Gert Doering <[email-masked]>
> *Cc:* [email-masked]
> *Sent:* Friday, 26 June 2015, 5:24
> *Subject:* Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy
> for bridging hotspots
>
>
> / I think another thing to remember is that "enablement" can imply a
> default. For example, if my car comes with a SIM slot, and I choose to
> put one on in it, then I've implicitly chosen that the car should by
> default use the connectivity provided by its own 3/4G connectivity. I'm
> also have likely to have chosen the particular SIM and its associated
> usage plan based on my expected usage of the Internet by and possibly in
> the car. If the car also has a Wifi hotspot in it, I'll likely associate
> my phone with it once, so that from then on my phone will automatically
> use the car's connectivity every time I get in it, without any
> intervention on my part at all. That would be much more convenient than
> having to switch on and off hotspot support on my phone each and every
> time I get in the car - and it is likely people will sometimes forget,
> and then try to do that while they're driving, which will be as or more
> dangerous than sending text messages while driving.
>
> / Having choice can be good, but you want to try to minimise both the
> amount of choices and how often people have to make them - too much
> choice can lead to paralysis, such that making no choice becomes the
> safest "choice".  I think when it comes to usability, predictable and
> expected defaults, and matching peoples' existing conceptual and mental
> models are much better. The book "The Design of Every Day Things" is an
> excellent book on making things easier to use.

I agree having choice is good.  Some cars already feature a 3-option 
menu where the car should get its Internet from.  That is good, but it 
is bad because the driver has to concentrate on it.

So some people came up with automating that choice.  That's not in the 
cars but maybe in the future.

The problem is that future will be very remote because there are so many 
choices of connectivity for the car, for the passengers.  Doesnt look 
simple to list all the choices, and to automate them.

And, worse, the protocols are not made to work in that dynamic way.

Alex

> / Regards,
> / Mark.
> [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Jun 2015 17:15:25 +0200

Le 26/06/2015 11:20, Philip Homburg a écrit :
>> For *you* this might make sense and be a useful feature.  For me, I
>> might like it, but will never actually use it (because I'm way too
>> lazy to be interested in multiple possible Internet uplinks for my
>> car - and why I should bother to trade the nice *external* antenna
>> of the car with the great reception of a typical smartphone inside
>> a large moving metal box).
>
> I hope that car manufacturers will find their way back into modular
> electronics, just like car radios ages ago.
>
> With he current rate of development, car electronics are obsolete for
> most of the car's lifetime.
>
> A good example is built-in navigation systems, where car manufactures
> have a hard time understanding what to charge for updating maps, so
> people just use a standalone device next to the built-in one.

I fully agree.  NAvigation systems continue to be a large fiasco since
they first appeared on the market.  There is still no easy way to update
them - IMHO the reason has to do with policy: who controls the car, who
writes the software, wo controls the communication system... these are
typically very different industries.

> Android devices typically receive their last update 1.5 years after
> the devices were last sold. Nice driving around with an unpatched,
> internet connected car entertainment system.

:-)

There is another tendency here: car manufacturers consider TomTom,
google and a few others to be the best source of information on
geography.  Whereas the best source of information comes from the
authority who controls these roads.

> With modular electronics, those who want their pi powered hadoop
> cluster can just by an aftermarket upgrade.

YEs, but car manufacturers dont want the same aftermarket upgrade to 
work on their cars as simply as it works on competition's cars, and 
that's a problem.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Fri, 26 Jun 2015 09:17:23 -0700

> On Jun 26, 2015, at 08:01 , Alexandru Petrescu <[email-masked]> wrote:
> 
> 
> 
> This is a great formulation of requirements but there is nothing else outside the car industry that did this kind of behaviour in the past. So it's not that easy to implement.  (typically a automated configuration is using RA/DHCP/NAT and these have a strong notion of directivity - client and server, provider and consumer; in the car setting you have two strongly opposed interests smartphone's and car's).

I disagree… HDMI provides some similar functionalities.

Many portable routers provide similar functionality in hotel rooms all over the place.

Apple’s airport products provide similar functionality.

There are MANY examples of similar functionality (albeit with a coarser UI) that abound.

For that matter, Internet Connection Sharing on MacOS X and Windows provides similar functionality.

> You dont have one protocol that can change roles dynamically.  A DHCP Server is a Server can't dynamically become a Client.  A NAT is in one direction cant dynamically change direction.

You don’t need it. It’s a very simple independent selection in two devices worst case:

	Phone:
		Internet Source:			[Carrier [|Wifi 1[|Wifi2…]]]
		[share internet with			optional menu of wifi and/or other networks, possibly allowing multi-select]

	Car:
		Internet Source:			[Carrier [|Phone 1[|Phone 2…]]]
		[share internet with			optional menu of wifi and/or other networks, possibly allowing multi-select]

If you choose Carrier in both cases, then both will independently access the internet via their respective carriers.

If you choose the Car’s wifi on the phone and the phone’s wifi on the car, then you get what you would expect — a disconnected LAN.

Not rocket science to configure and not hard for the end user to understand IMHO.

> 
> Worse - Internet addresses are centrally assigned and distributed, one can't make IP addresses out of nothing and reach the Internet bidirectionally.

Why is that a problem? That’s what DHCP-PD is for.

> 
> That's why it's easier if a decision were made (one of the two provides Internet to the other).

It’s a little bit (very tiny fraction) easier because one gets to implement a host instead of a router, but really not enough easier to be worth the loss in user functionality.

Heck, I can put everything needed together on a Raspberry PI for under $100 without writing any software of my own. 

> This is very strong requirements and difficult to meet.

See above… It’s already been met in the phone. The phone already has all the required functionality.
Why can’t the same functionality be implemented in a car with a larger form factor and greater power resources
with the ability to potentially support a larger codebase?

When did a more capable system become a bigger development challenge for basic functionality than
an embedded system? Somehow I missed the memo when that flip occurred.

> I wouldnt say laziness, some work hard at it, but it's not easy.

See above… It’s not hard, it’s been done, there’s open source code to do it.

Owen

---

From: David Schinazi <[email-masked]>
Date: Fri, 26 Jun 2015 11:40:34 -0700

Nick,

Sorry about the confusion, "bringing up IPv4 specifically" was speculation on my end.
I did mean a separate APN that could be used for hotspots and/or systems that do not support IPv6.
To support an IPv4-only device on a personal hotspot from an IPv6-only iOS handset, we would need some
type of translation from v4 to v6 on the iOS device. We currently do not provide that.

Thanks,
David

> On Jun 24, 2015, at 00:58, Heatley, Nick <[email-masked]> wrote:
> 
>  
>  
> From: v6ops [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of David Schinazi
> Sent: 24 June 2015 08:16
> To: [email-masked] <mailto:[email-masked]>
> Cc: Vividh Siddha
> When you say you imagine carries bringing up IPv4 specifically for personal hotspot, not sure what you mean - do you mean a parallel, dedicated “hotspot APN”?
> Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW
> 
>

---

From: Ross Chandler <[email-masked]>
Date: Sat, 27 Jun 2015 09:35:16 +0100

> On 26 Jun 2015, at 19:40, David Schinazi <[email-masked]> wrote:
> 
> Nick,
> 

David,

Does/could iOS allow this?

Handset APN name = Hotspot APN name

but with

Handset APN protocol = IPv6-only  & Hotspot APN protocol = IPv4-only

Best regards,
Ross

---

From: Erik Kline <[email-masked]>
Date: Sat, 27 Jun 2015 18:40:02 +0900

> I have long thought Apple's implementation of Happy Eyeballs is awesome.
> Tweaking the algorithm's built-in fudge factor to trend more towards IPv6
> would make it more consistent with other OSs and applications (which give
> 200-300ms Happy Eyeballs head start to IPv6, which is similar to the fudge
> factor done by Apple).  Myself, I would like the fudge factor to be
> configurable via sysctl or at least viewable via netstat (or similar).  As
> it is, it is difficult to understand why a system is heavily preferring IPv4
> or IPv6, and when it will give up; disconnecting and reconnecting the
> network is a harsh troubleshooting step for other traffic.

I *think* I've been having some moderate success with "route change
-inet 0.0.0.0 -rtt 5000000", but it's very hard to be sure...maybe
I've been lucky enough to be on really good IPv6 networks.  :)

---

From: <[email-masked]>
Date: Mon, 29 Jun 2015 14:51:49 +0200

Hi,

> My linux based non-Android machines do dhcp-pd ok.

Have you tried to run DHCP-PD via IPv6-capable USB dongles? The ones that I know of don't forward DHCPv6 requests to the network. So even if your OS supports it, it's most likely that you modem (or its chipset) does not support it.

-- 
Holger Metschulat 
Deutsche Telekom Technik GmbH 
E-Mail: [email-masked] 
http://www.telekom.de 
Erleben, was verbindet.  
Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik
Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Jun 2015 15:16:07 +0200

Le 29/06/2015 14:51, [email-masked] a écrit :
> Have you tried to run DHCP-PD via IPv6-capable USB dongles? The ones
>  that I know of don't forward DHCPv6 requests to the network. So even
>  if your OS supports it, it's most likely that you modem (or its
> chipset) does not support it.

Do you mean USB-Ethernet dongles?  No, I have not tried DHCPv6-PD on
USB-Ethernet dongles.

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.

I guess that hardware which blocks DHCPv6-PD also blocks DHCPv6.
Otherwise it would be an intentional blocking of DHCPv6-PD...

Alex