IPv6's failure was mostly caused by the IETF's ivory tower dwellers, who seem to generally have no practical experience or understanding whatsoever of how networks are actually built and run today, especially at the small to mid scale.

Small site multihoming, for example, is an absolute disaster. Good luck if you're trying to add a cellular backup to your residential DSL connection.

IETF says you should either have multiple routers advertising multiple provider-assigned prefixes (a manageability nightmare), or that you should run BGP with provider independent address space; have fun getting your residential ISP or cellular carrier onboard with this idea.

▲

pigggg an hour ago | parent | next [-]

IETF has a history of being hostile to network operators. I mean actual network operators - not the people who show up at conferences or work the mailing list who just happen to get a paycheck from a company that runs a network (and have zero production access / not on call / not directly involved in running shit). It's gotten better in the last few years in certain areas (and credit to the people who have been willing to fight the good fight). But it's very much a painful experience where you see good ideas shot down and tons of people who want to put their fingerprint on drafts/proposals - it's still a very vendor heavy environment.

	▲	bigfatkitten an hour ago \| parent [-]
		Even the vendor representatives are mostly getting paid to post on mailing lists and show up at conferences. They're not building products, and they're not supporting, visiting or even talking to their customers. Design-by-committee is a full time job that people actually building things for a living tend to not have time for.

▲

nine_k an hour ago | parent | prev [-]

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

▲

bigfatkitten an hour ago | parent [-]

> 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 an hour 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 30 minutes 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.

▲

patmorgan23 an hour 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 16 minutes 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.

▲

hdgvhicv 42 minutes 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 34 minutes ago | parent [-]

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

▲

hdgvhicv 33 minutes 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 32 minutes 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 20 minutes 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 36 minutes 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 25 minutes 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.