undefined

points

[-]

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.)

by cyberax3 hours ago|

parent|

[-]

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.

by clownstrikelol3 hours ago|

prev|

[-]

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.

by craftkiller2 hours ago|

parent|

[-]

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.

by cyberax1 hours ago|

parent|

prev|

[-]

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

by clownstrikelol1 minutes ago|

parent|

[-]

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