Egregoros

Signal feed

Timeline

Post

Remote status

Context

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

> The most common example is small branch sites with dual ISP uplinks. There are a vast number of these sites deployed using two small provider-assigned (PA) NAT pools. This setup is widely understood, simple to implement, and reliable.

> Moving these sites to IPv6 via BGP is often not feasible. Many ISP circuits do not support BGP, and the teams operating these sites lack the time to navigate that complexity. Furthermore, other IPv6 dual-homing options often don't align with enterprise requirements or expected complexity (or really simplicity) levels.

> In my view, this is a core reason why IPv6 adoption remains low in the enterprise space: it requires fundamental paradigm shifts rather than a simple protocol update.

so true
> 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! 😜 )
@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.

Replies

6
@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