~tore Tore Anderson's technology blog

Update: GitHub Pages, Fastly, and IPv6

When I created this blog a couple of years ago, I was disappointed to find out that the GitHub Pages service (GHP) did not support IPv6. This was due to the fact that GHP’s CDN provider Fastly didn’t support IPv6.

To work around this problem I ended up inserting a dual-stacked HTTP proxy service in front of my (IPv4-only) GHP-hosted blog. While it was hardly ideal, it did the trick.

The other day I was pleasantly surprised to find out that I no longer need this hack: Fastly and GHP now do support IPv6! IPv6 appears to have been enabled for https://toreanderson.github.io and all other GHP sites without requiring explicit opt-in. Perfect!

When did it happen? Well, it seems Fastly announced IPv6 availability on the 31st of March (after having had it in limited beta since last summer). Assuming Twitter is a reliable indicator, IPv6 was enabled for GHP specifically sometime between the 10th of April and the 28th of May.

I was quite critical of Fastly in those old posts, so it’s only fair that I congratulate them now. Well done, Fastly - I’m very happy to see you get on the IPv6 bandwagon!

IPv6 roaming in the United Kingdom

Earlier this week I visited the United Kingdom to attend the excellent UKNOF36 meeting.

As I usually do when when going abroad, I spent some time testing to what extent IPv6 works while roaming in the various PLMNs I have access to.

The previous posts in this series are:

Those posts contain some more technical background about the testing methodology, so I suggest you skim through them in order to better interpret the test results in this post.

Test results

O2 - MCCMNC 23410

Home PLMN Tech IPV6 PDP context IPV4V6 PDP context
Tele 2 Sweden 2G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 3G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 4G N/A N/A
Telenor Norway 2G Fails (cause 33) IPv4-only connection
Telenor Norway 3G Fails (cause 33) IPv4-only connection
Telenor Norway 4G N/A N/A

I was not able to get 4G coverage with any of my SIM cards in this network, which probably means that neither Tele 2 nor Telenor have a 4G roaming agreement with O2.

While in 2G and 3G coverage Tele 2 and Telenor’s HLR/HSS blacklisting trick comes into play. (See the IPv6 roaming in Belgium and Romania post for an explanation of what that trick is.)

Vodafone - MCCMNC 23415

Home PLMN Tech IPV6 PDP context IPV4V6 PDP context
Tele 2 Sweden 2G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 3G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 4G Fails IPv4-only connection
Telenor Norway 2G Fails (cause 33) IPv4-only connection
Telenor Norway 3G Fails (cause 33) IPv4-only connection
Telenor Norway 4G Works perfectly IPv4-only connection

In 2G and 3G coverage this looks like the standard HLR/HSS blacklisting trick. However the 4G behaviour is very unusual (as the blacklisting trick is specific to 2G and 3G).

IPv6-only PDP contexts work fine with my Telenor SIM card, but not with my Tele 2 one. My phone logs this latter failure as being due to an unknown/invalid cause code so I have no idea about what’s going on here.

Dual stack IPV4V6 PDP contexts do not work in 4G coverage with any of my SIM cards, and any attempt to use them results in IPv4-only connectivity. As this is not caused by Telenor and Tele 2’s blacklisting trick, the logical conclusion is that Vodafone is deliberately blocking dual stack PDP contexts from being used in their end.

I also saw very similar IPv6-hostile behaviour in Vodafone Romania’s network. I wonder if that is a coincidence or not.

3 - MCCMNC 23420

Home PLMN Tech IPV6 PDP context IPV4V6 PDP context
Tele 2 Sweden 2G N/A N/A
Tele 2 Sweden 3G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 4G N/A N/A
Telenor Norway 2G N/A N/A
Telenor Norway 3G N/A N/A
Telenor Norway 4G N/A N/A

It appears Telenor doesn’t have a roaming agreement with this operator (my phone reported no access to network). With my Tele 2 SIM card I could not get neither 2G or 4G coverage, only 3G. In 3G coverage Tele 2’s HLR/HSS blacklisting trick comes into play.

EE - MCCMNC 23430

Home PLMN Tech IPV6 PDP context IPV4V6 PDP context
Tele 2 Sweden 2G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 3G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 4G Works perfectly Works perfectly
Telenor Norway 2G Fails (cause 27) IPv4-only connection
Telenor Norway 3G Fails (cause 27) IPv4-only connection
Telenor Norway 4G Works perfectly Works perfectly

This looks pretty much as expected for an operator where the HLR/HSS blacklisting trick is being used to block IPv6 in 2G and 3G coverage. However, it’s the first time I’ve seen this result in 3GPP cause code 27 (missing or unknown APN). Usually I see code 33 (requested service option not subscribed). Not sure if this difference is significant somehow, but the outcome is the same in any case.

When in 4G coverage, both IPv6-only and dual stack PDP contexts worked just fine.

That said, I did have trouble getting dual stack to work in EE 4G coverage when I used another one of phones. Unfortunately I did not have time to investigate that further during my brief visit. Next time, perhaps.

IPv6 roaming in Belgium and Romania

I briefly visited Belgium and Romania last month. Using SIM cards from Tele 2 Sweden and Telenor Norway, both of which support the dual-stack IPV4V6 and IPv6-only IPV6 PDP context types, I spent some time testing whether or not I was able to get working IPv6 Internet connectivity while roaming in the various available PLMNs.

In many cases, IPv6-only connection attempts failed completely. Furthermore, dual stack connection attempts more often than not resulted in an IPv4-only Internet connection. Full test results below.

These frequent failures are however not as dramatic as they might sound. Both Tele 2 and Telenor are using a blacklisting trick that blocks their subscribers from using IPv6 when roaming in certain operators (whose IPv6 capabilities hasn’t yet been verified). See RFC 7445 section 3 and section 6 for technical details on how this trick works. When roaming in an operator blacklisted in this manner, IPv6-only connection attempts made in 2G/3G coverage will fail with 3GPP cause code 33 (requested service option not subscribed), while dual stack connection attempts will result in IPv4-only Internet connectivity.

The good news is that when my devices were set up to request dual-stacked IPV4V6 PDP contexts, they would in every single case get at least the same level of Internet connectivity as they would when requesting an IPv4-only IP PDP context; having the devices request dual-stacked connectivity had no downside whatsoever.

I’ve also performed the same kind of IPv6 roaming testing in Sweden a while back.

Test results

Belgian PLMNs

Proximus - MCCMNC 20601

Home PLMN Tech IPV6 PDP context IPV4V6 PDP context
Tele 2 Sweden 2G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 3G Fails (cause 33) IPv4-only connection
Telenor Norway 2G Works perfectly Works perfectly
Telenor Norway 3G Works perfectly Works perfectly

I was not able to test in 4G/LTE coverage, as it appears that neither Tele 2 nor Telenor have a 4G/LTE roaming agreement with Proximus.

Tele 2 is applying the blacklisting trick described above. Telenor, on the other hand, does not and IPv6 works perfectly.

Orange - MCCMNC 20610

Home PLMN Tech IPV6 PDP context IPV4V6 PDP context
Tele 2 Sweden 2G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 3G Fails (cause 33) IPv4-only connection
Telenor Norway 2G Fails (cause 33) IPv4-only connection
Telenor Norway 3G Fails (cause 33) IPv4-only connection

In the Orange PLMN I got identical behaviour with both my SIM cards. It appears both Tele 2 and Telenor are blacklisting, and there is no 4G/LTE roaming agreement.

As with Tele 2/Proximus, dual stack «works» in the sense that I get IPv4-only Internet connectivity.

BASE - MCCMNC 20620

Home PLMN Tech IPV6 PDP context IPV4V6 PDP context
Tele 2 Sweden 2G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 3G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 4G Works perfectly Works perfectly
Telenor Norway 2G Fails (cause 33) IPv4-only connection
Telenor Norway 3G Fails (cause 33) IPv4-only connection
Telenor Norway 4G Works perfectly Works perfectly

BASE demonstrates how the blacklisting trick only works on 2G/3G and not on 4G. Both Tele 2 and Telenor are blacklisting here, but nevertheless dual stack and IPv6-only works perfectly if the data PDP context is established while in 4G coverage.

Romanian PLMNs

Vodafone - MCCMNC 22601

Home PLMN Tech IPV6 PDP context IPV4V6 PDP context
Tele 2 Sweden 2G Fails (cause 32) IPv4-only connection
Tele 2 Sweden 3G Fails (cause 32) IPv4-only connection
Tele 2 Sweden 4G Fails (cause 32) IPv4-only connection
Telenor Norway 2G Fails (cause 32) IPv4-only connection
Telenor Norway 3G Fails (cause 32) IPv4-only connection
Telenor Norway 4G Fails (cause 32) IPv4-only connection

Vodafone is an interesting case. The fact that IPv6 and dual stack fails on 2G and 3G with 3GPP cause code 32 (service option not supported) instead of 33, and the fact that it also fails in the same way on 4G/LTE, indicate that this is not caused by the blacklisting trick. Instead, it would appear that Vodafone is deliberately blocking visitors from using of IPv6 on their network.

For operators such as Tele 2 and Telenor, this is not such a big deal, as dual-stack still «works» by falling back on IPv4-only connectivity. Operators using 464XLAT, on the other hand, will likely find Vodafone’s behaviour hugely problematic.

Telekom - MCCMNCs 22603 (2G) and 22606 (3G)

Home PLMN Tech IPV6 PDP context IPV4V6 PDP context
Tele 2 Sweden 2G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 3G Fails (cause 33) IPv4-only connection
Telenor Norway 2G Fails (cause 33) IPv4-only connection
Telenor Norway 3G Fails (cause 33) IPv4-only connection

Identical results as with Orange in Belgium. I was unable to get 4G/LTE coverage, and both Tele 2 and Telenor applies blacklisting on 2G/3G.

Digi.Mobil - MCCMNC 22605

Neither Tele 2 nor Telenor seems to have any form of roaming agreement with this operator, at least I was completely unable to register in their network, and thus unable to perform any IPv6 testing.

Orange - MCCMNC 22610

Home PLMN Tech IPV6 PDP context IPV4V6 PDP context
Tele 2 Sweden 2G Fails (cause 33) IPv4-only connection
Tele 2 Sweden 3G Fails (cause 33) IPv4-only connection
Telenor Norway 2G Works perfectly Works perfectly
Telenor Norway 3G Works perfectly Works perfectly
Telenor Norway 4G Works perfectly Works perfectly

Tele 2 does not appear to have a 4G/LTE roaming agreement with Orange, and the blacklisting trick is being used on 2G/3G.

With Telenor, on the other hand, there’s no blacklisting and both IPv6-only and dual stack works perfectly on all technologies.

IPv6 roaming in Sweden

UPDATE 2017-10-15: The information in this post is outdated, see this post for an updated version.

There has been much talk about IPv6 potentially causing problems for subscribers roaming between mobile networks. There’s an entire RFC dedicated to the possible failure cases, and it has even been claimed that «until every carrier has activated IPv6 there is no way to activate IPv6 for international roaming».

My own personal experience with IPv6 roaming hasn’t been quite that bleak, so I’ve therefore decided to thoroughly test IPv6 roaming whenever I have the chance and chronicle the results here, one post per country I visit.

As I am currently attending Internetdagarna 2016 in Stockholm, I now have the opportunity to perform this testing for Sweden.

There are four mobile network operators in Sweden. However, the only one I could roam in while using my Telenor Norway SIM card appeared to be Telenor Sweden. (No big surprise, there.) Thus I was only able to test the Telenor Sweden PLMN.

The tests were performed by separately attempting to establish single-stack IPV6 and dual-stack IPV4V6 data bearers and then visiting ds.test-ipv6.com. This procedure was repeated for all available access technologies I was able to use. The results were as follows:

Visited PLMN MCCMNC Tech IPV6 bearer IPV4V6 bearer
Telenor Sweden 24024 2G 10/10 (IPv6-only) 10/10 (dual stack)
Telenor Sweden 24008 3G 10/10 (IPv6-only) 10/10 (dual stack)
Telenor Sweden 24008 4G 10/10 (IPv6-only) 10/10 (dual stack)

Thus I can conclude that IPv6 roaming in the Telenor Sweden PLMN works 100% perfectly. Kudos to Telenor Norway and Telenor Sweden for making that happen!

IPv6 support in the PlayStation 4

The other day, I noticed with great interest that my PlayStation 4 was using IPv6 to communicate with the Internet. I’m fairly certain that this behaviour is new, so I decided to investigate.

This is what appeared on the wire when it connected to the network:

  1 0.000000000           :: -> ff02::16     ICMPv6 110 Multicast Listener Report Message v2
  2 0.072956000           :: -> ff02::1:ffe2:19c7 ICMPv6 78 Neighbor Solicitation for fe80::2d9:d1ff:fee2:19c7
  3 0.799982000           :: -> ff02::16     ICMPv6 90 Multicast Listener Report Message v2
  4 1.600965000 fe80::2d9:d1ff:fee2:19c7 -> ff02::16     ICMPv6 90 Multicast Listener Report Message v2
  5 2.957012000 fe80::2d9:d1ff:fee2:19c7 -> ff02::2      ICMPv6 70 Router Solicitation from 00:d9:d1:e2:19:c7
  6 2.970763000 fe80::385a:20ff:fe70:f441 -> fe80::2d9:d1ff:fee2:19c7 ICMPv6 270 Router Advertisement from 3a:5a:20:70:f4:41
  7 2.971328000 fe80::2d9:d1ff:fee2:19c7 -> ff02::1:2    DHCPv6 110 Solicit XID: 0xe0e8c5 CID: 0003000100d9d1e219c7
  8 2.973796000 fe80::385a:20ff:fe70:f441 -> fe80::2d9:d1ff:fee2:19c7 DHCPv6 191 Advertise XID: 0xe0e8c5 CID: 0003000100d9d1e219c7 IAA: 2a02:fe0:c071:f00a::f1e
  9 2.974148000 fe80::2d9:d1ff:fee2:19c7 -> ff02::1:2    DHCPv6 152 Request XID: 0xe0e8c5 IAA: 2a02:fe0:c071:f00a::f1e CID: 0003000100d9d1e219c7
 10 2.977070000 fe80::385a:20ff:fe70:f441 -> fe80::2d9:d1ff:fee2:19c7 DHCPv6 223 Reply XID: 0xe0e8c5 CID: 0003000100d9d1e219c7 IAA: 2a02:fe0:c071:f00a::f1e
 11 2.977472000           :: -> ff02::1:ff00:f1e ICMPv6 78 Neighbor Solicitation for 2a02:fe0:c071:f00a::f1e
 12 3.000971000 fe80::2d9:d1ff:fee2:19c7 -> ff02::16     ICMPv6 90 Multicast Listener Report Message v2
 13 3.400970000 fe80::2d9:d1ff:fee2:19c7 -> ff02::16     ICMPv6 90 Multicast Listener Report Message v2
 14 3.977343000 fe80::2d9:d1ff:fee2:19c7 -> ff02::1:ff70:f441 ICMPv6 86 Neighbor Solicitation for fe80::385a:20ff:fe70:f441 from 00:d9:d1:e2:19:c7
 15 3.977615000 fe80::385a:20ff:fe70:f441 -> fe80::2d9:d1ff:fee2:19c7 ICMPv6 86 Neighbor Advertisement fe80::385a:20ff:fe70:f441 (rtr, sol, ovr) is at 3a:5a:20:70:f4:41
 16 3.977874000 2a02:fe0:c071:f00a::f1e -> 2a02:fe0:1:2:1:0:1:110 DNS 103 Standard query 0xc4e3  AAAA ena.net.playstation.net
 17 3.987868000 2a02:fe0:1:2:1:0:1:110 -> 2a02:fe0:c071:f00a::f1e DNS 241 Standard query response 0xc4e3  CNAME ena.net.playstation.net.edgekey.net CNAME e4963.dscg.akamaiedge.net AAAA 2a02:26f0:ac:181::1363 AAAA 2a02:26f0:ac:197::1363
 18 3.988383000 2a02:fe0:c071:f00a::f1e -> 2a02:26f0:ac:181::1363 TCP 94 62420→80 [SYN] Seq=0 Win=65535 Len=0 MSS=1440 WS=64 SACK_PERM=1 TSval=415148157 TSecr=0
 19 4.005888000 2a02:26f0:ac:181::1363 -> 2a02:fe0:c071:f00a::f1e TCP 94 80→62420 [SYN, ACK] Seq=0 Ack=1 Win=28560 Len=0 MSS=1440 SACK_PERM=1 TSval=3194590031 TSecr=415148157 WS=32
 20 4.006231000 2a02:fe0:c071:f00a::f1e -> 2a02:26f0:ac:181::1363 TCP 86 62420→80 [ACK] Seq=1 Ack=1 Win=65664 Len=0 TSval=415148175 TSecr=3194590031
 21 4.006361000 2a02:fe0:c071:f00a::f1e -> 2a02:26f0:ac:181::1363 HTTP 166 GET /netstart/ps4 HTTP/1.1
 22 4.021963000 2a02:26f0:ac:181::1363 -> 2a02:fe0:c071:f00a::f1e TCP 86 80→62420 [ACK] Seq=1 Ack=81 Win=28576 Len=0 TSval=3194590047 TSecr=415148175
 23 4.022418000 2a02:26f0:ac:181::1363 -> 2a02:fe0:c071:f00a::f1e HTTP 587 HTTP/1.1 403 Forbidden  (text/html)
 24 4.022479000 2a02:26f0:ac:181::1363 -> 2a02:fe0:c071:f00a::f1e TCP 86 80→62420 [FIN, ACK] Seq=502 Ack=81 Win=28576 Len=0 TSval=3194590048 TSecr=415148175
 25 4.022780000 2a02:fe0:c071:f00a::f1e -> 2a02:26f0:ac:181::1363 TCP 86 62420→80 [ACK] Seq=81 Ack=503 Win=65152 Len=0 TSval=415148191 TSecr=3194590048
 26 4.022849000 2a02:fe0:c071:f00a::f1e -> 2a02:26f0:ac:181::1363 TCP 86 62420→80 [FIN, ACK] Seq=81 Ack=503 Win=65664 Len=0 TSval=415148191 TSecr=3194590048
 27 4.037492000 2a02:26f0:ac:181::1363 -> 2a02:fe0:c071:f00a::f1e TCP 86 80→62420 [ACK] Seq=503 Ack=82 Win=28576 Len=0 TSval=3194590063 TSecr=415148191
 28 4.045960000 2a02:26f0:ac:181::1363 -> 2a02:fe0:c071:f00a::f1e TCP 86 [TCP Dup ACK 27#1] 80→62420 [ACK] Seq=503 Ack=82 Win=28576 Len=0 TSval=3194590071 TSecr=415148191
 29 4.046281000 2a02:fe0:c071:f00a::f1e -> 2a02:26f0:ac:181::1363 TCP 74 62420→80 [RST] Seq=82 Win=0 Len=0

There are several things I find noteworthy here:

  1. It supports DHCPv6. Since the DHCPv6 client runs in user space, this strongly indicates that it’s a deliberate move by Sony.
  2. It performs DNS requests over IPv6. A stub resolver also runs in user space, so it’s another indication that this is not accidental.
  3. It uses IPv6 to call home to the dual-stacked URL http://ena.net.playstation.net/netstart/ps4.
  4. The call home URL returns a 403 Forbidden error. However, it does so when accessed using IPv4 as well, so this might not mean much.

For the record, the call home request does not include any personal information beyond the source IP address and a URL indicating it’s a PS4. That said, the request itself is more than enough for Sony to generate useful statistics on how many PS4s with IPv6 Internet access there are out there. The following is the complete call home request made:

GET /netstart/ps4 HTTP/1.1
Connection: close
Host: ena.net.playstation.net

So far I’ve not seen it use IPv6 for anything else than what I’ve described above. An application like Netflix, which ought to use IPv6 whenever possible, does not. It would appear, therefore, that this is just small beginnings, perhaps done primarily to gather statistics. Nevertheless, I am very excited to see that Sony has begun work on implementing IPv6 support for the PS4.

Technical details

I first noticed the IPv6 capability after upgrading to system software version 3.50. I can’t rule out that it showed up in an earlier update, though, since I haven’t actively looked for it after installing earlier updates.

I tested various different network environments to figure out what exactly the PS4 supports. It would appear that Sony has done a thorough job:

  • It supports assignment of global IPv6 addresses using both SLAAC and DHCPv6 IA_NA. When using SLAAC, the Interface Identifier appears to be randomly generated. That is, the IID does not embed the PS4’s MAC address, and it changes every time the PS4 reconnects to the network.
  • It will learn IPv6 DNS servers from both the Recursive DNS Server RA Option and DHCPv6.
  • Addresses and/or DNS servers learned from DHCPv6 are preferred over those learned from ICMPv6 Router Advertisements (if any).
  • It will start a DHCPv6 client only if either the Managed or OtherConfig RA flag is set. If Managed=1, it will solicit both IA_NA and DNS configuration; otherwise, if OtherConfig=1, it will send a DHCPv6 Information-request message to obtain DNS configuration only.

I did find a couple of bugs too:

  • It would sometimes attempt to use its link-local address to communicate with the DNS server or the HTTP call-home web server, which doesn’t work. This suggests that there is a bug in the PS4’s default address selection logic, or that it failed to activate its SLAAC- or DHCPv6-assigned address. Simply re-connecting to the network would usually resolve this issue.
  • If address assignment is SLAAC-only, and the advertised prefix is off-link, no IPv6 Internet traffic is seen. In this case, the PS4 does not even start the DHCPv6 client even though OtherConfig=1. This is clearly a bug; there’s no reason why SLAAC can’t work perfectly well with off-link prefixes.

The next time I get a system software update, I’ll make sure to re-do all these tests and report any changes in a new post.