IPv6 support

It would be nice if flightaware.com supported IPv6. Currently the homepage is IPv4 only and the feed URL if I’m not mistaken is an IPv4 literal address (70.42.6.197) rather than a hostname which could contain both A and AAAA records.

In the meantime I’ve issued a pull request to enable IPv6 by default on the flightaware dump1090 fork on github. This will at least enable IPv6 by default in lighttpd on the PIAware image.

No home user NEEDS IPv6 and many are disabled. If the internal links from FA page-to-page is via IP address, this is an amateur webmaster mistake. This prohibits multiple servers (say in the cloud) and various load balancing techniques. It also prohibits moving the host server to another ISP. Internal references are best when accessing the docroot, “/other/location/page” or via the http url “http : // domainName / pagename”

You are mistaken. Comcast, one of the largest ISP’s in the United States has IPv6 enabled by default along with many others. It’s 2019, IPv6 is a reality and it’s here to stay.

A common misconception is that the only advantage of IPv6 is the larger address space. That couldn’t be further from the truth. The larger address pool that IPv6 provides is just one of the many advantages of IPv6.

Here’s a short list of the advantages of IPv6 I stole from Quora

  • Less need for stateful NAT/PAT/NAPT
  • Ability to assign unique link-local addresses on the fly without depending on a router or DHCP server.
  • Ability to pick an address from thin air (SLAAC)
  • Ability to change addresses frequently (Privacy Addressing)
  • Ability to belong to many networks simultaneously, with a unique address on each.
  • Less need for readdressing and refactoring of networks thanks to big address space.
  • Easy to combine multi-enterprise networks without readdressing.
  • Ability to do nondisruptive readdressing in the fly with deprecated addressing model.

I was referring to the feed URL, which is where all the location data is sent. Users never see that URL. But since you brought it up, let’s say a user is accessing the piaware web interface directly via the RFC 1918 IPv4 address which is what the majority of users do. Now let’s say that user wants to access their piaware remotely. The user assumes that they can simply type in the RFC 1918 address in the address bar of their browser as they do at home and are flummoxed when they are instead presented with an error.

Now let’s assume the user is using the pi’s IPv6 address to access the gui. Regardless of what network the user is connected to, at home or remotely, they can access their piware using the same URL. This is one example where IPv6 provides benefits to home users.

I’ve assigned a hostname to my piaware box that resolves to the pi’s IPv6 address. That way whether I’m at home or on the road I can access the gui using the same address regardless of my physical location.

2 Likes

Try piaware-config adept-serverhosts piaware-ipv6.flightaware.com
(The v6 addresses are not in the default name because reliable v6 is not sufficiently widespread)

3 Likes

Additionally, while commercial sites use IPv6 regularly, home users and their routers and systems seldomly support it well, if at all. The NAT and SPI features all provide layers of protection, while home anti-virus software does not protect from v6-tunneling into v4 systems. Oh well – it’s not my problem.

1 Like

Nice! Thanks for providing this information. I had no idea you had IPv6 support. After running that command I see that the adept-serverhosts has been updated.

piaware-config -showall
adept-serverhosts              piaware-ipv6.flightaware.com   # value set at /etc/piaware.conf:9

Google, Facebook, Netflix and countless other companies are dual-stack by default. In other words, IPv6 is preferred over IPv4 when it’s available for some of the largest companies on the net. Why the hesitation to change the default adept-serverhosts to a hostname that contains both A (IPv4) and AAAA (IPv6) records? That way if IPv6 is available it would be used, otherwise IPv4 would be used.

In regards to being able to claim a device when using IPv6 it looks like the claim page already supports IPv6. I see my IPv6 address listed next to my IPv4 address. Maybe allow the user to claim a PiAware if they’re coming from an IPv6 IP that resides in the same /64 as the PiAware? Or make the claim process IPv4 only for now?

Lastly, can you provide any information on the status of my PR to enable IPv6 in lighttpd?

Thanks

Mostly because there are plenty of systems out there where global IPv6 connectivity is apparently present, but is actually nonfunctional (notably the various v6 peering issues that can make large chunks of the address space randomly unreachable). We’d rather not eat random connection timeouts or hung connections when the bulk of installs have working v4. For specific cases where v6 is useful, it can be turned on, but it’s not a great default.

(edit: one option that might work is to load the v6-only hostname at the end of the list of candidate hosts in the default configuration, so v6 will be used if all the v4 options fail)

My personal experience with Netflix + IPv6 was that it just doesn’t work, because their geolocation database didn’t know about my address range and refused to serve me any content; and there was no way to bypass the use of v6 without turning off v6 system-wide. A poor user experience.

1 Like

Searching the /64 is probably reasonable. Though the preferred way to claim the device these days, assuming you’re using the sdcard image, is to follow the claim link from the top-level status page; this pairs the UUID with a user account without caring about the IP at all.

Have not had a chance to test it. My main concern would be whether lighttpd will start OK with that config on a system with IPv6 disabled.

1 Like

That’s a valid concern. Google, Facebook, Netflix, YouTube etc would be risking serious profits if there weren’t solutions to the issues you’ve outlined above. However, by utilizing the best practices outlined in RFC 6555 aka “Happy Eyeballs” the application should seamlessly transition to IPv4 when such issues occure.

That’s a step in the right direction and would certainly provide connectivity to IPv6 only users.:grinning: Ensuring the IPv6/IPv4 fail over mechanism works as expected would also go a long way. Once that’s been fully tested then eventually you’d be able to add a dual-stack hostname.

If you were running IPv6 over IPv4 via a tunneling provider such as tunnelbroker.net that might explain why you were having issues. Netflix stopped allowing those IP’s access due to fact that there’s no way for them to determine your real location.

Good point. I hadn’t thought of that. If IPv6 is completely disabled then they won’t even get a link-local address. I’ll do some additional testing.

I’d take a PR that implements this for piaware.

This implies you already have a fail-over mechanism. No? In other words, if dump1090 can’t connect to the first host in the list it tries the second, third and so on until it connects. I saw in a previous post where you mentioned that you can enable dual-stack functionality by modifying the adept server to “piaware-ipv6.flightaware.com piaware.flightaware.com

Granted more testing would have to be done but it sounds as if you already have a working solution for IPv6 that just needs to be tested?

No need to reinvent the wheel. It sounds like you already have a fail-over mechanism.

Counter examples: Verizon FIOS doesn’t offer IPv6. CoxCable just enabled it, but not for the Business or G1gablast customers.

I had to hardcode the IPv4 address in /etc/hosts to force IPv4 for the initial connection to claim my PIAware :wink: Then, I removed the entry to use IPv6

But, indeed, matching on a /64 should be the way to go

Just use the following URL to claim your feeder directly. The feeder-id can be obtained via piaware-status.

https://flightaware.com/adsb/piaware/claim/

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.