Egregoros

> Then we get to IPv6.

> Each router has a prefix from its upstream provider via DHCPv6-PD. Each downstream interface gets an address from that upstream's delegated prefix.

> Each host now has prefix information coming from two different routers, and installs two different prefixes. Hosts that use SLAAC or DHCPv6 get addresses dynamically, one from each upstream router.

> Devices that need static addresses like NFS servers have two addresses, one from each upstream provider's delegated prefix.

> Default route information is handed out dynamically to autoconfiguring hosts via RAs, since DHCPv6 isn't allowed to pass along default route information.

> For statically addressed hosts, a static default gateway can be configured to a VRRPv6 link-local v6 address, with all the chaos involved in having to statically assign link-local addresses.

> Now, when [ISP 1]'s link goes away, VRRPv6 can change priorities so that the default gateway flips to [ISP 2]'s router. Yay!

> Unfortunately, there's nothing that tells the downstream host "hey, stop using that address as a source address for connections". So, the host continues trying to use [ISP 1]'s prefixed address as a source IP for connections, even though the default gateway is now going out through [ISP 2]. [ISP 2], being a good network, sees what looks like IP spoofing going on, and drops the outbound packets.

> Host keeps trying ineffectively to establish an outbound connection using the [ISP 1] prefix address, because there's no way to signal the statically addressed host "hey, stop using that prefix as a source address, use the other address you have instead"

> Eventually, after enough failures, the user gives up and turns off IPv6.


☝️☝️☝️☝️☝️☝️☝️☝️☝️

> You seem to be denying the existence of all the small businesses in the world.

> Given that Google estimates there are 200 to 400 million enterprises with less than 50 employees worldwide, that's a pretty big chunk of the business world to ignore.

> Or are you suggesting that 400 million small businesses should get their own ASNs and provider independent IPv6 space, and use BGP to gain redundancy for their businesses?

> (talk about driving a demand for more router RAM for the DFZ core! 😜 )

@feld
>There is also a significant set of use cases that currently work better, or at least more easily, with NAT.

This one especially is so obvious, but every time benefits of NAT are mentioned, they get ignored. Not to mention the dumbness of your smart fridge having a network unique and publicly routable address. NAT sucks for hosting on a (home) network, but it also trivial to hide your (home) network from the public just by routing all/most traffic through a node and NATting it there if your setup needs outbound traffic as well. v6 can do the same thing the same way, but uttering the word NAT makes people mad.

@Nimbius666 you're missing the point. I have worked with many small businesses that have dual ISPs for redundancy. There's no mechanism to support this properly with IPv6. It just doesn't exist. The routing can fail over, but the clients have no way to be informed that they can't use the source IP addresses from the ISP that is down.

So now you have to use NPTv6 or NAT66, or BGP if you have your own address space. And we really really don't want everyone getting their own address space. The routing tables will explode.

@feld
>They just like that they can have free static IPs for their homelabs. That's it. There's nothing more to it really.

Of course completely oblivious to the fact that they probably got something stupid as /1XX or even better a /64 representing maybe 25 devices in that address space at best. The rest nowhere to be found. Sure seems like a waste of address space coming from people that complain about the lack of address space in v4.

---

Also looking at the ML thread, it's funny how it's basically people scheming how to kill v4.

@feld dfz is already an enormous headache since the advent of dual stack, but isps seem to be able to cope (it needs a rework). I still think if your business expects this level of redundancy its no longer really small and should consider a local provider that can implement an as for you.

That said, I'm stumped. Multi home seems to be one of two ideas

Give end hosts 3 IP addresses: a ULA address for traffic internal to the enterprise, and a DHCPv6-PD address from each ISP for internet traffic. This preserves IP transparency (so, no NAT/NPT), but also means you lose control over load balancing as the network edge will have to policy route based on whatever source address the end hosts select. This also gets complicated (or impossible) when dealing with another layer 3 routing device inside the edge as it would require prefixes to be re-delegated further into the network (at this point we are a delegation engine for traffic)

Give end hosts a GUA, but translate it at the edge to the appropriate egress DHCPv6-PD address space. NPT may not be an option because there's no guarantee that all of the prefix lengths will match, so this probably requires using NAT66. On the bright side, path selection is now back with the network, but then there's no guarantee that all applications will actually work through NAT66, notwithstanding the ideological heresy of using translation with IPv6.

Neither is great 😒

@Nimbius666

> I still think if your business expects this level of redundancy its no longer really small and should consider a local provider that can implement an as for you.

There are lots of situations where you're really still a small business but need the redundancy. There are other situations where you're required by regulations to have redundancy (e.g., ambulance companies) but you'd still qualify as a small business.

The problem is that all over the USA there are places where people need this and they have two options: a shitty DSL provider and a shitty Cable company. Neither one will be able to give you BGP or implement an AS for you.

IPv6 is just broken by design for excluding these extremely valid use cases.

@Nimbius666

sctp: nobody uses this in the real world because it's blocked by too many middleboxes. also, completely useless for normal traffic which is TCP/UDP anyway.

multipath TCP: how many OSes do you think actually implement multipath TCP support? I'll give you a hint, it's two: MacOS/iOS. Three if you count Linux but it barely has support. FreeBSD has none, only some network stack forks experimenting with it (it was the original testbed of it).

MTCP doesn't work at all unless both client and server support it.

This is the wrong layer to solve this problem