upvote
> if your Internet connection goes down and the router withdraws the prefix

My router advertises both the public prefix from my ISP and a ULA prefix for internal LAN connections (essentially the IPv6 equivalent to RFC-1918). This gives me stable local addresses that do not change and work without public internet access.

https://en.wikipedia.org/wiki/Unique_local_address

reply
> My router advertises both the public prefix from my ISP and a ULA prefix for internal LAN connections

You'd think so, but you'd be wrong. If you have a GUA and a ULA, and the printer has both a GUA and a ULA, then your host is going to prefer the GUA when connecting to the printer.

So when a router withdraws a prefix, it's possible for your computer to still have a (stale) GUA while the printer only has a ULA. Whoops, and your printing is broken.

There is an RFC in review that would fix this: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda... . It'll likely be approved in 2027, so you'd be able to use ULAs some time in the 2030-s once it trickles down.

reply
That RFC does look like a nice improvement! Until then, since both devices have a ULA address, wouldn't simply deleting the printer from your phone/computer and re-adding it resolve the issue? Doing it when your public internet is down would probably even be best to ensure you're getting the ULA instead of GUA, thereby avoiding this issue entirely in the future.

(Admittedly I haven't had a printer for over a decade and I have never printed from a phone, so maybe I am missing something.)

reply
In practice, nobody uses IPv6 for printers, so it'll work just fine over IPv4.

I used a printer as an example of a local device, it can be any other device: a smart lightbulb, a TV you're casting to, a SIP phone, etc. And I used Android as an example of a device where you can't easily change the source address selection preference.

What is more shocking is that this problem has been known for three decades, yet somehow nobody cared enough to fix it. And it's far from the only issue.

reply
Ditch advertising public addresses to local devices at all.

Have the router issue ULAs only and let the router do stateless NPT (network prefix translation) only.

Done, works great. Doesn’t matter what your internet connection is doing.

Yes, your local devices will use the ULA to attempt to connect to Internet destinations if that’s the only v6 address they have. It works fine.

reply
While this is going to be fine for many users, wouldn't this continue our reliance on STUN for UDP hole punching? I'd certainly prefer a world where peer-to-peer networking is less reliant on work-arounds created for the NAT era.
reply
> Have the router issue ULAs only and let the router do stateless NPT (network prefix translation) only.

This is an option, but ULAs are ranked _below_ IPv4 in address selection preferences. So your network will essentially operate in IPv4 mode: https://www.ietf.org/archive/id/draft-buraglio-6man-rfc6724-...

Moreover, some devices will refuse to connect to IPv6 GUA with ULA addresses altogether.

> Yes, your local devices will use the ULA to attempt to connect to Internet destinations if that’s the only v6 address they have. It works fine.

You're half right. The devices will work fine because they won't be using IPv6 at all.

As I said, IPv6 is a recursive WTF.

How do I know that? I made a personal goal to create a dualstack demo network that is fully standards compliant and supports the bare minimum functionality that I would expect from a SOHO network. So far, I keep finding new and exciting breakages on every level.

reply
> This is an option, but ULAs are ranked _below_ IPv4 in address selection preferences. So your network will essentially operate in IPv4 mode

If they don’t have an v4 address then they don’t have that problem.

NPT solves the issue of your devices losing global addresses.

Ideally you wouldn’t need NPT, and you should have an RA for the ULA and an RA for the GUA and then use the ULA locally... but then you end up with a different problem (and why I didn’t do it at home). Doing this means you have little control about which upstream ISP gets chosen. I have two ISPs at home, and router will failover between them; however, even though I have PI IP space, finding a residential ISP that will let me use it is nearly impossible (good luck finding someone there who even knows what BGP is).

So the tradeoff here for me is not letting my devices have a GUA so that my router can control outbound traffic policy completely (like it can with v4), and just NPT it to what I need it to be externally. Works great (but again, if you only have one global prefix you need to deal with, separate RAs for ULA/GUA do work better).

> You're half right. The devices will work fine because they won't be using IPv6 at all.

Not if they don’t have an IPv4 address to begin with!

You can also coax your local DNS resolver to... just not let A records through if the name also has an AAAA record.

Even better than that would be out of the box like magic 464XLAT in home routers / ISPs. As it is 464XLAT is not the nicest thing in the world to configure; however, it does work very well, and does allow for a network to be entirely v6 except at the very edge. Heck, I’d love it if enterprise gear had “like magic” 464XLAT too. Would make a lot of things easier.

> How do I know that? I made a personal goal to create a dualstack demo network that is fully standards compliant and supports the bare minimum functionality that I would expect from a SOHO network. So far, I keep finding new and exciting breakages on every level.

If you really want to accomplish that, completely forget about trying to make dual stack work throughout the network. It’s an exercise in frustration, mostly in needing to duplicate config in v4 and v6, and you will inevitably have them end up out of sync with each other.

464XLAT is good standard here, DNS64 with a NAT64 does also work... for things with names at least.

One of the other comments around here about not providing a “migration plan” does have a lot of truth to it. If, 30 years ago, they envisioned 464XLAT and made it part of the default features a v6 capable router should have, I bet v4 would be long dead (or nearly there) by now.

reply
The extension headers are fine, because they frequently are not needed, so the fact that they are optional allows the IPv6 header to be significantly simpler than the IPv4 header, which has some seldom used fields which are always present.
reply
No, they are not fine. Their design means that the router needs to know all possible extension headers to just be able to route the packets. Oh, and you also have to do offset-chasing in the hardware fastpath.

As a consequence, IPv6 with extension headers are just dropped by routers in the public Internet.

reply
deleted
reply
If it works with mainstream Linux, sounds like an Android problem
reply
That's not a very good example.

1) I can count on one hand the number of times my Internet connection has gone down in the past 5 years.

2) I can count on zero hands the number of times I've tried to print from a phone, ever.

reply
I explained the problem in a sibling post on this thread.

But you want a more complex challenge? Here you go!

You have a small business office that has two Internet uplinks for redundancy. You want to balance the load across them and failover broken links.

This can be done with literally zero setup with IPv4.

reply
I do admit this is a challenge. The only reason it's "easy" with IPv4 is because of NAT. With IPv6 you'll need prefix translation. I've found someone with a failover solution for UniFi but in general you are correct, it's a pain: https://github.com/mattackerman808/ipv6-wan-failover
reply