> a cellular backup to your residential DSL connection

Hmm, what's the problem? I suppose your home devices should never be exposed to the public internet, and should only be accessible via a VPN like Wireguard. NAT64 is a thing if your home network is IPv4.

BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?

▲

toast0 an hour ago | parent | next [-]

> BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?

Yes, an interface can hsve two separate IPv6 addresses, but that doesn't make it easy.

If you do the easy and obvious thing of setting up two routers to advertise their prefix with your preferred priority when they're available (and advertise it as unavailable when they're not), your devices are likely to configure themselves for addresses on both prefixes, which is great.

Then when you open a new tcp connection (for example), they'll pick a source address more or less randomly... There's a RFC suggestion to select the source address with the largest matching prefix with the destination address, which is useful if the prefix is pretty long, but not so useful when the prefix is 2001:: vs 2602::

Anyway, once the source address is selected, the machine will send the packet to whichever router most recently sent an announcement. Priorities only count among prefixes in the same announcement. If you manage to get a connection established, future packets will use the same source address, but will be sent as appropriate for the most recently received advertisement.

This is pretty much useless, if you want it to work well, you're better off with NAT66 and a smart NAT box.

▲

bigfatkitten 3 hours ago | parent | prev [-]

> BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?

Because it breaks your network when that router goes away. Your switch ACLs, firewall rules, and DNS records all become invalid because they contain addresses that no longer exist, that your devices continue trying to reach anyway.

▲

nine_k 2 hours ago | parent | next [-]

Ah, I understand what you likely mean saying "small site multihoming": not a Web site (where it would be trivial), but e.g. a small office.

But with multi-homing you would need to actively test which of your uplinks has Internet access anyway, won't you? And you would have to react somehow when one of your uplinks goes down.

It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.

I still assume that you don't want the internals of your office network directly accessible via the public Internet, even when you easily can; VPNs exist for a reason.

▲

bigfatkitten 2 hours ago | parent [-]

In the IPv4 world, it's easy. Just use NAT, and forward everything over your preferred bearer. Have your router ping 8.8.8.8 or something periodically from that WAN interface to verify reachability. If your preferred link goes down, make your backup link the primary route, clear your NAT translation table, and your local devices remain mostly oblivious that anything happened.

> It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.

In the IPv6 world, this is pretty much what you have to do. A whole lot of extra complexity and expense that you didn't have previously.

	▲	Dylan16807 an hour ago \| parent [-]
		Extra complexity and expense? You're describing basically the same thing they are. A router that does NAT and decides which link to send the packets over based on connection testing. And IPv6 has the benefit of a significantly simpler 1:1 NAT.

▲

magicalhippo an hour ago | parent | prev | next [-]

Had to move away from pfSense due to this. It just wasn't possible to stop it giving my devices its public IP as DNS.

So every time I got a new prefix, machines would lose connectivity, usually until I rebooted them.

Switched to OpenWRT which respected my ULA.

▲

patmorgan23 2 hours ago | parent | prev [-]

You should be using dynamic DNS and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes.

▲

bigfatkitten 2 hours ago | parent | next [-]

> You should be using dynamic DNS

That doesn't solve the problem. DNS remains broken until each and every device, assuming VERY generously that it is capable of dynamic DNS at all, realises that one of its prefixes has disappeared and it updates its DNS records. With DNS TTL and common default timeouts for prefix lifetime and router lifetime, that can take anywhere from 30 minutes to 30 days.

> and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes.

This requires you to assign one VLAN per device, unless perhaps you've got lots of money, space, and power to buy high end switches that can do EVPN-VXLAN so that you can map MAC addresses to SGTs and filter on those instead.

▲

magicalhippo an hour ago | parent | prev | next [-]

> any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes

In the case of pfSense this is a recent change. It was not supported when I migrated away from it less than five years ago.

▲

hdgvhicv 2 hours ago | parent | prev | next [-]

I want to send my ssh via my low latency reliable connection, I want to route my streaming via another connection. That’s just a routing rule and srcnat in ipv4

That’s before you go on to using PBR. I want to route traffic with different dscp via different routes.

Ultimately I want the rout g to be handled by the network, not by the client.

IPv4 and nat makes that a breeze.

▲

sekh60 2 hours ago | parent [-]

How is it not a routing rule with ipv6? Firewalls and routers typically support dynamic prefixes (even Vyos, pfSense, openSense do).

▲

hdgvhicv 2 hours ago | parent [-]

How do I tell my phone that I want to send traffic to server A via isp1 and server B via isp2

▲

sekh60 2 hours ago | parent [-]

On your router?

edit Less flippantly, what are you wanting to base the routing rule on? What's your ipv4 routing rule?

DSCP is allowed in ipv6.

https://www.juniper.net/documentation/us/en/software/junos/c...

	▲	hdgvhicv 2 hours ago \| parent [-]
		Without nat, my understanding is the right way in v6 is to issue addresses of every network and then send a message to each end device asking it to use a specific ip address to route traffic and hope every client implements RFC 4191 in the right way.

▲

sekh60 2 hours ago | parent | prev [-]

The amount of ignorance in these ipv6 posts is astounding (seems to be one every two months). It isn't hard at all, I'm just a homelabber and I have a dual-stack setup for WAN access (HE Tunnel is set up on the router since Bell [my isp] still doesn't give ipv6 address/prefixes to non-mobile users), but my OpenStack and ceph clusters are all ipv6 only, it's easy peasy. Plus subnetting is a heck of a lot less annoying that with ipv4, not that that was difficult either.

▲

transcriptase 2 hours ago | parent [-]

“it’s easy peasy” says guy who demonstrably already knows and has time to learn a bunch of shit 99.9% of people don’t have the background or inclination to.

People like you talking about IPv6 have the same vibe as someone bewildered by the fact that 99.9% of people can’t explain even the most basic equation of differential or integral calculus. That bewilderment is ignorance.

	▲	Dylan16807 an hour ago \| parent [-]
		These people apparently had the time and inclination to learn a bunch of shit about IPv4, though. "Easy" is meant in that context. The people acting like the IPv4 version is easy. So your second paragraph doesn't fit the situation at all.