IPv6 with Sonic ONT

[ngufra]

Note that Sonic does not support static IP with fiber.
I also use blue iris. Note that blue iris, at least for the android app, uses an "IPS" to match a subset of the license key to a deployment so it can work with a dynamic IP without any third party requirement.
For using blue iris with http, i use a dynamic dns provider (noip.com). As I don't want to remember their name, I have a cname in my zone records to point from a name in my domain (home.<mydomain.org>) to the name from noip.com (in .ddns.net)
On the router I have a redirection from a port, say 8443, to the local machine running blue iris on the port it's running. so I could have multiple instances of blue iris or any other http services, just not on the same port. And it works everywhere.

[graeme_stewart]

I'm about to move from AT&T to Sonic fiber (looking forward to it!) but the lack of IPv6 is disappointing, specifically, I use a home Wireguard VPN, and have both v4 and v6 resolution, will lose the v6 access when Sonic switches over. This was especially useful when running the VPN client on mobile (T-Mobile specifically) who's primary access model is IPv6.

I've no doubt I could probably get this working if a) I use Sonic provided gateway, b) set up the IPv6to4 tunnel, and c) was ok with the substantially reduced throughput such an architecture provides.

Since I'm strongly opposed to using Sonic provided hardware I'm effectively losing IPv6 connectivity. Native IPv6 to fiber customers is the "last piece" for it to be an absolute "no-brainer" in recommending Sonic.

[aanon4]

Here's an old thread about IPv6 on fiber back in 2017 - viewtopic.php?f=13&t=4902 - it was coming soon back then too. Despite what may be said, there's obviously no value for Sonic to offer this otherwise it would have happened.

[dane]

Best way that I can characterize it has been that we have had other priorities. It’s not essential, whereas automating and scaling up our ability to engineer and manage the deployment of huge amounts of new fiber was.

[tigertech]

even if there's no immediate payout

I would again like to gently push back against this. There would be an immediate benefit to Sonic, which is that dual-stack makes it more likely that a subscriber can connect to a given service that supports both IPv4 and IPv6 (which is most of them now). This wasn't one of the original intended design benefits of IPv6, but it's turned out to be a practical one.

I suspect Sonic often gets calls saying "I can't connect to [Netflix / Hulu / some big website]", and it turns out to be something on an IPv4 transit network between Sonic and the provider that can't be fixed by either end.

If there was an IPv6 path, though, it's likely the customer wouldn't have the same problem, because the paths are likely to be different -- and most dual-stack clients, including web browsers, will try to connect to whichever works better (or at all).

So dual-stack IPv4 and IPv6 makes many network connections appear to be more reliable from a consumer perspective, and I think Sonic would get a payoff from that.

Anyway, glad to hear from Dane that it's still in the works.

[jfa_roy]

I'm a new Sonic fiber customer (ex-comcast) and I too was annoyed by the lack of IPv6. I need it for my work (specifically testing that IPv6 works properly). Please do not under-estimate the value of IPv6 to your "pro" or more technical customers.

That being said, I spent the time to setup the Sonic tunnel with my UDM Pro router. It's ... janky, because the new UniFi OS stack also has really poor IPv6 support (I'm holding Ubiquiti's feet to the fire more on that one), but it can be done. I mostly followed instructions from https://gist.github.com/BGrewell/591b5c ... 921cecef60 and https://community.ui.com/questions/This ... 39dd0630e7. In your LAN network, you can then enable static IPv6, carve out a /64 from the "network" /60 that Sonic gives you, assign ::1 as the gateway out of it, enable DHCPv6 and advertise the rest of the range to your LAN.

But again, I don't want to have to do that long term!

[msiegen]

Here's reason to believe that Sonic is making progress.

In a newly built part of Sonic's network in Santa Rosa, my router is actually receiving a default IPv6 route already:

Code: Select all

# ip -6 route show dev enp3s0
fe80::/64 proto kernel metric 256 pref medium
default via fe80::b68a:5fff:fe97:5f94 proto ra metric 1024 expires 1794sec hoplimit 64 pref medium

There are a few hosts visible on the segment (this interface is plugged directly into the ONT in bridge mode):

Code: Select all

# ip -6 neigh show dev enp3s0
fe80::224:45ff:fefa:e087 lladdr 00:24:45:fa:e0:87 router STALE
2001:5a8:0:7::9e lladdr b4:8a:5f:97:5f:94 router STALE
fe80::b68a:5fff:fe97:5f94 lladdr b4:8a:5f:97:5f:94 router STALE

The global address (2001:5a8:0:7::9e) is pingable from the internet and appears to be the same box that also provides DHCPv4 services (judging from reverse DNS lookups, and my router's DHCP logs).

I haven't tried pulling a DHCPv6 lease yet, because I'm remote and don't want to fiddle with the router when I'm not there to fix my mistakes. I wouldn't expect it to work, yet, per Dane's recent comments here. But clearly some parts of the infrastructure are in place!

[julianoster]

Interesting, @msiegen. On a by now older part of the fiber network in SF, I have been getting two router advertisements for a long time now, but wasn't actually able to exchange any packets with them. In fact, for the router my interface chooses as the default route, I cannot even ping that advertised router (neighbor solicitation packets appear to get unanswered).

But I definitely saw nothing with a non-link local address, as you do. So, in order not to confuse things by having IPv6 packets trying to go out through the defunct advertised gateway, instead of my tunnel interface, I disabled IPv6 on the interface that is directly attached to the ONT for now.

[tomoc]

As Dane has mentioned, we have had our hands busy with other, more time sensitive matters. We do, however, care very much about bringing native IPv6 (dual stack) to our fiber network. The unfortunate reality of the situation is that every RG vendor has it's IPv6 stack implementation which comes with it's own set of hurdles. We want to be sure to deliver the best customer experience we possibly can, so we have been working to resolve any issues we can catch ahead of time with known vendors on our platform.

Our core and access networks are ready to go, and although vendor interop has slowed things down, we are determined to launch dual stack connectivity in the very near future.

[jfa_roy]

As Dane has mentioned, we have had our hands busy with other, more time sensitive matters. We do, however, care very much about bringing native IPv6 (dual stack) to our fiber network. The unfortunate reality of the situation is that every RG vendor has it's IPv6 stack implementation which comes with it's own set of hurdles. We want to be sure to deliver the best customer experience we possibly can, so we have been working to resolve any issues we can catch ahead of time with known vendors on our platform.

Our core and access networks are ready to go, and although vendor interop has slowed things down, we are determined to launch dual stack connectivity in the very near future.

That's great to hear. A few questions:

- Will you offer more than one /64?
- Will there be an opt-in or "lab" or "early access" period?
- Is near future "this quarter", "this year", "within the next X years"?
- Will enablement be staged across markets/geos/cities? Will some markets/geos/cities not get IPv6 because of old equipment or other issues?