Why you need IPv6(blog.ungleich.ch)
blog.ungleich.ch
Why you need IPv6
https://blog.ungleich.ch/en-us/cms/blog/2018/05/23/why-you-need-ipv6/
93 comments
Can you describe the routing problem a bit more in detail? I'm trying to understand why multi link should be more a problem in IPv6 than in IPv4.
If you are multi homed it sounds as if you should have your own /48 IPv6 network (PI) and then only use the link addresses for routing - but maybe there is something that prevents you from - looking forward to hear your fully story!
If you are multi homed it sounds as if you should have your own /48 IPv6 network (PI) and then only use the link addresses for routing - but maybe there is something that prevents you from - looking forward to hear your fully story!
Multi-homed doesn’t help when you have two links to two different ISPs that you want to load balance. You need NAT for that. Also, I haven’t looked at multi-homing costs but I assume they are not free (let me know if I’m wrong). Plus in a small office or retail location, you don’t need a consistent public IP when you aren’t hosting servers (or they are only via VPN).
What. If your ISP is not terrible, it just takes a route advertisement to switch the same IP address between networks. And route the same subnet through multiple networks.
There is no need for OSPF, RA is good enough. The ISP just has to not filter them out and forward into routing.
(You will have to inform them that you use a specific separate subnet on your network. This means typically a business contract.)
Not all ISPs offer this functionality. I can’t realistically tell the customers I manage that we can’t support their preferred provider because of this, when they rightly point out that it just works on IPv4 without need for multi-homing.
And again, multi-homing does not address load balancing / policy based routing with active active links. Eg it’s possible to have 2 Ethernet connections, 1 VDSL connection and a LTE link. Can multi-homing IPv6 work in such a situation while providing fast failover and load balancing by service/application/policy?
And again, multi-homing does not address load balancing / policy based routing with active active links. Eg it’s possible to have 2 Ethernet connections, 1 VDSL connection and a LTE link. Can multi-homing IPv6 work in such a situation while providing fast failover and load balancing by service/application/policy?
I wonder as well. The main downside I have heard about IpV6 until now is that many softwares are not compatible.
I have to admit there is actually some. Luckily though, when we saw problems, recent updates (i.e. mosh, ping, etc.) actually fixed them.
However there is some really broken software out there that hard codes IPv4 addresses - which even breaks NAT64/DNS64!
However there is some really broken software out there that hard codes IPv4 addresses - which even breaks NAT64/DNS64!
I've got the exact same issue.
The solution when I investigated was to use IPv6 network prefix translation; however most routers do not support it (including Mikrotik routerOS, which is what I mostly use).
So lacking that, instead I've gotten my own AS and am now a 'proper' internet peer.
The solution when I investigated was to use IPv6 network prefix translation; however most routers do not support it (including Mikrotik routerOS, which is what I mostly use).
So lacking that, instead I've gotten my own AS and am now a 'proper' internet peer.
So... you have multiple advertising routes, and each box has 5 public addresses, and the complaint is that the boxes can't magically decide how to handle all of the different routes?
When it comes to routing, you have two options, delegate or self-manage. In the case of self-management, yes, if you want complex route management, then you'll need software that handles complex route management.
Why not use Stateless DHCP, and configure a machine with short leases that can update the others as needed? It can handle the complex routing, and the clients just have to frequently ask if there are updates.
When it comes to routing, you have two options, delegate or self-manage. In the case of self-management, yes, if you want complex route management, then you'll need software that handles complex route management.
Why not use Stateless DHCP, and configure a machine with short leases that can update the others as needed? It can handle the complex routing, and the clients just have to frequently ask if there are updates.
In my case, I want to fail over from VDSL to 4G within a couple seconds of VDSL going down. Will short leases cover that?
I also like to load balance traffic on another site with two VDSL links and a 4G backup. I can’t do that without NAT.
I also like to load balance traffic on another site with two VDSL links and a 4G backup. I can’t do that without NAT.
DHCP traffic is approximately 512 bytes in each direction for each half lease period. Stick 1000 clients on a single node, with 2 second leases, and you'll use 0.5% of your bandwidth, and be able to update your default gateway every second
Leases? What leases, this is not DHCP. If you mean Route Advertisement with short life, then yes.
The leases referenced by the post I was replying to:
“Why not use Stateless DHCP, and configure a machine with short leases”
How do you deal with one missed RA causing an inadvertent failover to using a different WAN, while maintaining 1-2s failover after the first WAN link goes down?
Also this does not fix the issue with inability to load balance without NAT. Eg I have a desktop (or tablet etc) that I want to send VoIP out one WAN and everything else out another.
“Why not use Stateless DHCP, and configure a machine with short leases”
How do you deal with one missed RA causing an inadvertent failover to using a different WAN, while maintaining 1-2s failover after the first WAN link goes down?
Also this does not fix the issue with inability to load balance without NAT. Eg I have a desktop (or tablet etc) that I want to send VoIP out one WAN and everything else out another.
Sounds like you should have your own PI space if you have multiple uplinks, and have that PI space advertised out across all four links. Then you can route packets however/wherever you want using whatever policy you'd like.
This is cost prohibitive, and I doubt most residential ISP's have the capability for this. I would like to have both a cable and a DSL ISP for redundancy but it's far from straightforward with IPv6 (and I have run IPv6 networks for not far off 20 years).
You are so far outside the norm here... Do prefix translation, it's like NAT, but run ULA space inside.
Now you can load balance across all your links without issues.
Now you can load balance across all your links without issues.
How is this particular situation better with ipv4?
In IPv4 people have accepted that NAT is the best they'll ever get and it's pretty easy to do redneck multihoming by round-robin NATing a private network behind multiple public IPs. In contrast, some people thought IPv6 was going to violate the laws of physics in their favor so they're disappointed that it hasn't happened.
BGP, most likely.
They evangelize for IPv6 ... and then they ask for money for a single /64? Seriously?
I would suggest anyone who wants a tunnel should look here:
https://tunnelbroker.net/
Nothing wrong with earning money, but please stop selling broken products.
I would suggest anyone who wants a tunnel should look here:
https://tunnelbroker.net/
Nothing wrong with earning money, but please stop selling broken products.
We absolutely agree: if possible, use free tunnel services.
Unfortunately HE does not work with NAT (sic!), which is why we initially rolled out IPv6 VPNs internally. Also in most combinations you can actually use miredo/teredo, however some of our customer networks block teredo traffic, because they don't want their windows machines to be reachable from the IPv6 internet.
Just curious, why do you think it is a broken to sell IPv6 vpns?
Unfortunately HE does not work with NAT (sic!), which is why we initially rolled out IPv6 VPNs internally. Also in most combinations you can actually use miredo/teredo, however some of our customer networks block teredo traffic, because they don't want their windows machines to be reachable from the IPv6 internet.
Just curious, why do you think it is a broken to sell IPv6 vpns?
It is broken to sell single /64s, that is not a sensible allocation size across administrative boundaries. A /56 would be the absolute minimum, and really it should be a /48.
I pretty much agree with the article. Seems like quite a few of the .com companies exist because consumers don't have public IP's. With IPv6 suddenly replacing various services are easy. Assuming you have a router, raspberry Pi, or other machine you leave on 24/7.
After all seems like most end user use of the cloud could be replaced by a raspberry Pi. Things like file sharing via dropbox, webcams/security cams, photo sharing/browsing, internet enabled door locks and garage doors, and monitoring temperatures, furnace, AC, solar, power use,
Sure it's a bit of work, but I suspect many would happily run things themselves if there was a community solution that did it well. Last thing anyone wants to do is replace their smarthone because a random vendor died, lost interest, or was purchased. Like say google killing off Revolv after they bought Nest. Not to mention paying even a few $ a month for an internet enabled lock is silly.
After all seems like most end user use of the cloud could be replaced by a raspberry Pi. Things like file sharing via dropbox, webcams/security cams, photo sharing/browsing, internet enabled door locks and garage doors, and monitoring temperatures, furnace, AC, solar, power use,
Sure it's a bit of work, but I suspect many would happily run things themselves if there was a community solution that did it well. Last thing anyone wants to do is replace their smarthone because a random vendor died, lost interest, or was purchased. Like say google killing off Revolv after they bought Nest. Not to mention paying even a few $ a month for an internet enabled lock is silly.
> Seems like quite a few of the .com companies exist because consumers don't have public IP's
That only works if you pass around an ugly IP(v6) address. DNS is still a thing, because humans didn't like passing around pure IPv4 addresses, IPv6 addresses are even less human-readable.
That only works if you pass around an ugly IP(v6) address. DNS is still a thing, because humans didn't like passing around pure IPv4 addresses, IPv6 addresses are even less human-readable.
Your comment makes no sense. No one is passing around IP addresses by hand. It sounds like you have not heard of dynamic DNS, and don't understand how P2P software works.
https://en.wikipedia.org/wiki/AAAA_record
https://en.wikipedia.org/wiki/Dynamic_DNS
https://en.wikipedia.org/wiki/Peer-to-peer
Can you please learn how basic networking works before posting on the topic of IPv6?
https://en.wikipedia.org/wiki/AAAA_record
https://en.wikipedia.org/wiki/Dynamic_DNS
https://en.wikipedia.org/wiki/Peer-to-peer
Can you please learn how basic networking works before posting on the topic of IPv6?
Of course I know how DNS and dynamic DNS work.
> Seems like quite a few of the .com companies exist because consumers don't have public IP's
This comment is suggesting that dynamic DNS companies would go under because of IPv6, which is absurd.
Can you please learn how to read before jumping to conclusions? It's fairly easy, I promise.
> Seems like quite a few of the .com companies exist because consumers don't have public IP's
This comment is suggesting that dynamic DNS companies would go under because of IPv6, which is absurd.
Can you please learn how to read before jumping to conclusions? It's fairly easy, I promise.
Not with that measily 480mbps USB controller split between 4USBs and 1 Ethernet. RaspberryPi4 hopefully.
The Raspberry Pi Foundation seems deadset on pushing the same genre of chip from Broadcom forward. I doubt the serious bandwidth limitations (all your I/O going over 1 USB port) or the notable chipset flaws (1GB of ram max) will be amended any time soon. They've had 6 years to fix the Raspberry Pi, yet it still has the same hard limits.
IDK I'm hoping the RPI4 will arrive when 4K starts become more prevalent and can do the HVEC decoding
HEVC on the next generation of Raspberry Pi is highly unlikely due to both licensing costs and Broadcom not having a cheap IP block to use for adding HEVC. 4K is more likely, but if you want that today go get an OrangePi for less than the cost of a Raspberry Pi. It even has HEVC 8bit support!
What online service is giving you 480mbps or better?
haha thats theoretical. Real world is 2-3MB/s over lan. Also Ethernet is 100mbit
This sounds an order of magnitude lower than RPi 3 B+ published network performance benchmarks, you should get around 250 Mbit/s = 30+ MBytes/s. Also, it's gigabit ethernet now.
(reference: https://libre.computer/2018/03/21/raspberry-pi-3-model-b-rev...)
(reference: https://libre.computer/2018/03/21/raspberry-pi-3-model-b-rev...)
> You want to expose services of your home network? You can fiddle around with NAT, hack some proxies and waste a lot of time and energy on this setup.
> With IPv6, you can assign every device in your network a public IPv6 address and decide on your router / firewall, which services to expose publicly.
Yeah, I used to think like this. Now I'm older and wiser (grumpier? lazier?) and because with great power comes great responsibility.. and everyone (including me) is running shitty router boxes instead of a perfectly tuned OpenBSD gateway... I think it would be really nice to have it but I'm not sold it will make the internet a safer place, instead it will expose all those IoT devices that can be wormed.
I also wanted to self-host stuff at home. Back when I had access to a basement (and no proper connection) running decent hardware was no problem, now in an apartment even a small silent NAS is annyoing enough already. Also I don't have no high hopes the fiber market in Germany will improve to a point where I can reasonably assume to have more than 10/20Mbit of upstream behind a static IP.
So yeah, this is a freedom for (from my PoV) a few percent of people, the rest won't bother or it will actively cause problems because nobody understands IPv6 firewalling and stuff. (Not you, dear readers, the masses that are happy if their wifi at home works, at all).
> With IPv6, you can assign every device in your network a public IPv6 address and decide on your router / firewall, which services to expose publicly.
Yeah, I used to think like this. Now I'm older and wiser (grumpier? lazier?) and because with great power comes great responsibility.. and everyone (including me) is running shitty router boxes instead of a perfectly tuned OpenBSD gateway... I think it would be really nice to have it but I'm not sold it will make the internet a safer place, instead it will expose all those IoT devices that can be wormed.
I also wanted to self-host stuff at home. Back when I had access to a basement (and no proper connection) running decent hardware was no problem, now in an apartment even a small silent NAS is annyoing enough already. Also I don't have no high hopes the fiber market in Germany will improve to a point where I can reasonably assume to have more than 10/20Mbit of upstream behind a static IP.
So yeah, this is a freedom for (from my PoV) a few percent of people, the rest won't bother or it will actively cause problems because nobody understands IPv6 firewalling and stuff. (Not you, dear readers, the masses that are happy if their wifi at home works, at all).
My cable ISP added IPv6 some years ago and recently my router finally got stable IPv6 support, so I decided to give it a try.
My use-case was exactly what the article highlights, putting my RPi on the net exposing a service.
As I quickly found out DNS was required, as the IPv6 addresses were just impossible to remember. The prefix I got from the ISP was a far cry from the 2001::42 shown in various articles on IPv6.
Then I discovered the prefix wasn't stable across cable modem reboots, and I used autoconfig on the RPi, so the suffix wasn't stable either. So that meant I dynamic DNS was suddenly a required feature, not an optional thing.
After spending half a day trying and failing to find a dynamic DNS service which supported IPv6 and which supported a client I could successfully and reliably use on my RPi, I gave up and went back to plain old IPv4 and NAT.
My use-case was exactly what the article highlights, putting my RPi on the net exposing a service.
As I quickly found out DNS was required, as the IPv6 addresses were just impossible to remember. The prefix I got from the ISP was a far cry from the 2001::42 shown in various articles on IPv6.
Then I discovered the prefix wasn't stable across cable modem reboots, and I used autoconfig on the RPi, so the suffix wasn't stable either. So that meant I dynamic DNS was suddenly a required feature, not an optional thing.
After spending half a day trying and failing to find a dynamic DNS service which supported IPv6 and which supported a client I could successfully and reliably use on my RPi, I gave up and went back to plain old IPv4 and NAT.
That's impressive to hear. If that is still the case, we will implement and offer an IPv6 DDNS service mid future.
Seriously. If you are blocked for using IPv6 by this, we will provide this service and announce it on https://twitter.com/datacenterlight.
Seriously. If you are blocked for using IPv6 by this, we will provide this service and announce it on https://twitter.com/datacenterlight.
Cheers, I'll keep a look out.
Not sure how common it is for "home ISPs" to issue unstable prefixes, but that's what I got so...
Not sure how common it is for "home ISPs" to issue unstable prefixes, but that's what I got so...
The fact that every device in your network is given a publicly reachable IP address is not something to brag about. It’s a security problem.
I’ll stick to my NAT, thank you.
I’ll stick to my NAT, thank you.
This trope needs to die. Just because a device has a publicly-routable IP does not mean that it’s freely-accessible. That’s why we have stateful firewalls.
There are millions of IPv4 systems at large enterprises and educational institutions that have public addresses, and do you think they’re accessible from the internet? Didn’t think so. They’re behind a default-deny stateful firewall, very similar in function to the stateful firewall that’s present on every single consumer router you can buy.
NAT is a hack that breaks things, and imposes un-needed performance bottlenecks.
There are millions of IPv4 systems at large enterprises and educational institutions that have public addresses, and do you think they’re accessible from the internet? Didn’t think so. They’re behind a default-deny stateful firewall, very similar in function to the stateful firewall that’s present on every single consumer router you can buy.
NAT is a hack that breaks things, and imposes un-needed performance bottlenecks.
I'm not so sure that this trope needs to die; it has a grain of truth to it, at least for home users. Consider this situation: I'm browsing the web on my laptop at home. Meanwhile, someone wants to hack into my laptop. Suppose they want to start with a simple port scan. If my ISP only gave me an IPv4 address, the attacker is out of luck: my laptop HAS NO NAME. They can send IP packets to my router, but unless the router itself has unusually serious security holes (such as remote code execution), the router will not send packets to arbitrary ports on my laptop, because there is no way to even ask it to do so. The best they can try to do is inject content into web pages I'm browsing, and https prevents even that.
Now I get IPv6. The attacker now has a perfectly reasonable way to send packets to my laptop. The router's job is to look at these packets and drop some of these packets while not dropping those that I rely on to browse the web, or whatever. Result: I am one bad config away from having my laptop be accessible from the internet.
You mention large enterprises. Sure, they can afford good sys admins. But the average computer user is their own sys admin. Are they ready for this job?
And if you say "yes", then here's the follow-up question: are they ready to administer the use-cases in sliken's comment, and still remain secure? https://news.ycombinator.com/item?id=17140187
Now I get IPv6. The attacker now has a perfectly reasonable way to send packets to my laptop. The router's job is to look at these packets and drop some of these packets while not dropping those that I rely on to browse the web, or whatever. Result: I am one bad config away from having my laptop be accessible from the internet.
You mention large enterprises. Sure, they can afford good sys admins. But the average computer user is their own sys admin. Are they ready for this job?
And if you say "yes", then here's the follow-up question: are they ready to administer the use-cases in sliken's comment, and still remain secure? https://news.ycombinator.com/item?id=17140187
Are you sure your router has PCP or NAT-PMP disabled, which _could_ expose ports on your external IPv4 IP without any interaction? Do you expect the average computer user to configure PCP securely on their router?
Various NAT traversal options are already pretty widespread. Having only a firewall keeps things much simpler.
Various NAT traversal options are already pretty widespread. Having only a firewall keeps things much simpler.
> Having only a firewall keeps things much simpler.
Yes, for you and for attackers. Security strategies require layers, since no one layer can be depended upon to stand on its own. Removing NAT is removing a layer of security. Suddenly your firewall has to stand on its own. Good luck!
Edit: Why is my comment bad?
Yes, for you and for attackers. Security strategies require layers, since no one layer can be depended upon to stand on its own. Removing NAT is removing a layer of security. Suddenly your firewall has to stand on its own. Good luck!
Edit: Why is my comment bad?
NAT is not a layer of security. At all. A billion layers of no security is still no security.
(And actually, NAT is a negative contribution to security as it hides the lack of a firewall when it isn't there or doesn't work, which would be trivial to detect without NAT.)
(And actually, NAT is a negative contribution to security as it hides the lack of a firewall when it isn't there or doesn't work, which would be trivial to detect without NAT.)
> it has a grain of truth to it, at least for home users
No, it doesn't.
> Suppose they want to start with a simple port scan.
Then they shouldn't find any services running on your laptop?
> If my ISP only gave me an IPv4 address, the attacker is out of luck: my laptop HAS NO NAME.
Yes, it does. It's called an IPv4 address. If you also happen to use NAT (which you didn't specify--believe it or not, but you can actually use IPv4 without NAT!), it happens to be a globally ambiguous address. Which doesn't change that it's a name.
Also, your computer has tons of other names via which it can be reached: email addresses, ad networks that your browser loads from, any other ways to send you messages with URIs for you to open and load code from to be executed inside your browser and thus on your LAN, and also all the ports on the NAT gateway's globally unique address that all your outbound connections have been mapped to. Those are all ways to access both attack surface on your machine, and potentially also on other devices on your LAN.
> They can send IP packets to my router, but unless the router itself has unusually serious security holes (such as remote code execution), the router will not send packets to arbitrary ports on my laptop, because there is no way to even ask it to do so.
There is a completely trivial way: You address it to the (globally ambiguous) address of your laptop. That is, unless there happens to be a stateful firewall on that router. But that stateful firewall would work just as well without NAT.
Also, why are you even so afraid of sending packets to "arbitrary ports"? Is your system drowning in malware that opens backdoors left and right? What is so dangerous about your system sending a few TCP resets and ICMP port unreachables?
> Now I get IPv6. The attacker now has a perfectly reasonable way to send packets to my laptop. The router's job is to look at these packets and drop some of these packets while not dropping those that I rely on to browse the web, or whatever. Result: I am one bad config away from having my laptop be accessible from the internet.
In other words: Just as with IPv4. Also, no you are not. There is nothing dangerous about receiving a packet. That seems to be some sort of irrational fear of some people, but it's really just bullshit. The attack surface reachable via email and browsers tends to be magnitudes larger than "oh my god, they can send me packets!!111".
> You mention large enterprises. Sure, they can afford good sys admins. But the average computer user is their own sys admin. Are they ready for this job?
They are as ready as they are for IPv4. They buy or rent a router from their ISP, and the ISP hopefully will continue to supply properly configured devices. They largely managed to do so with IPv4, so there is little reason to think they couldn't do so with IPv6.
> And if you say "yes", then here's the follow-up question: are they ready to administer the use-cases in sliken's comment, and still remain secure? https://news.ycombinator.com/item?id=17140187
Are they managing to prevent incompetent or malicious cloud providers from misusing or mishandling their data? Is their current setup as secure as you seem to assume it is? Also, why should there even be anything "to administer" in the first place? Just because NAT requires port forwarding, which then requires "administration", doesn't mean one has to continue this idiotic tradition with IPv6.
No, it doesn't.
> Suppose they want to start with a simple port scan.
Then they shouldn't find any services running on your laptop?
> If my ISP only gave me an IPv4 address, the attacker is out of luck: my laptop HAS NO NAME.
Yes, it does. It's called an IPv4 address. If you also happen to use NAT (which you didn't specify--believe it or not, but you can actually use IPv4 without NAT!), it happens to be a globally ambiguous address. Which doesn't change that it's a name.
Also, your computer has tons of other names via which it can be reached: email addresses, ad networks that your browser loads from, any other ways to send you messages with URIs for you to open and load code from to be executed inside your browser and thus on your LAN, and also all the ports on the NAT gateway's globally unique address that all your outbound connections have been mapped to. Those are all ways to access both attack surface on your machine, and potentially also on other devices on your LAN.
> They can send IP packets to my router, but unless the router itself has unusually serious security holes (such as remote code execution), the router will not send packets to arbitrary ports on my laptop, because there is no way to even ask it to do so.
There is a completely trivial way: You address it to the (globally ambiguous) address of your laptop. That is, unless there happens to be a stateful firewall on that router. But that stateful firewall would work just as well without NAT.
Also, why are you even so afraid of sending packets to "arbitrary ports"? Is your system drowning in malware that opens backdoors left and right? What is so dangerous about your system sending a few TCP resets and ICMP port unreachables?
> Now I get IPv6. The attacker now has a perfectly reasonable way to send packets to my laptop. The router's job is to look at these packets and drop some of these packets while not dropping those that I rely on to browse the web, or whatever. Result: I am one bad config away from having my laptop be accessible from the internet.
In other words: Just as with IPv4. Also, no you are not. There is nothing dangerous about receiving a packet. That seems to be some sort of irrational fear of some people, but it's really just bullshit. The attack surface reachable via email and browsers tends to be magnitudes larger than "oh my god, they can send me packets!!111".
> You mention large enterprises. Sure, they can afford good sys admins. But the average computer user is their own sys admin. Are they ready for this job?
They are as ready as they are for IPv4. They buy or rent a router from their ISP, and the ISP hopefully will continue to supply properly configured devices. They largely managed to do so with IPv4, so there is little reason to think they couldn't do so with IPv6.
> And if you say "yes", then here's the follow-up question: are they ready to administer the use-cases in sliken's comment, and still remain secure? https://news.ycombinator.com/item?id=17140187
Are they managing to prevent incompetent or malicious cloud providers from misusing or mishandling their data? Is their current setup as secure as you seem to assume it is? Also, why should there even be anything "to administer" in the first place? Just because NAT requires port forwarding, which then requires "administration", doesn't mean one has to continue this idiotic tradition with IPv6.
Hmm, good points, now that you mention it. Thanks.
> public addresses
That is part of the problem. Just as "private addresses".
They are globally unique and globally ambiguous addresses. There is nothing "public" or "private" about them.
That is part of the problem. Just as "private addresses".
They are globally unique and globally ambiguous addresses. There is nothing "public" or "private" about them.
I would argue that these are private addresses:
Class A Networks 10.0.0.0 to 10.255.255.255 with /8
Class B Networks 172.16.0.0 to 172.31.255.255 with /12
Class C Networks 192.168.0.0 to 192.168.255.255 with /16
So, if you would argue ... where is your argument then?
Also, IPv4 hasn't had address classes for a quarter of a century.
Also, IPv4 hasn't had address classes for a quarter of a century.
Implement security properly and stop worrying about it.
If your devices have open services with vulnerabilities. AND You completely forgot or didn't bother to use a firewall. AND Your devices are using permanent instead of temporary IPv6 addresses.
THEN you might have a problem.
But it's more likely that your badly protected IoT devices are downloading their software updates from a HTTP site without SSL or checksum verification while using a DNS vulnerable to cache poisoning.
If your devices have open services with vulnerabilities. AND You completely forgot or didn't bother to use a firewall. AND Your devices are using permanent instead of temporary IPv6 addresses.
THEN you might have a problem.
But it's more likely that your badly protected IoT devices are downloading their software updates from a HTTP site without SSL or checksum verification while using a DNS vulnerable to cache poisoning.
Temporary v6 addresses are not a security measure, they're a privacy measure. (And a weak one at that.)
An attacker can get route advertisements from your subnet if something is misconfigured on ISP side so they get out and do a tiny bit of inference to figure out which device it is.
An attacker can get route advertisements from your subnet if something is misconfigured on ISP side so they get out and do a tiny bit of inference to figure out which device it is.
NAT accidentally and poorly gives you security through obscurity.
Use a firewall.
Use a firewall.
No, it doesn't. NAT alone does not prevent inbound connections. You need a stateful firewall in addition to the NAT for that. And if you have that, well, yeah, you obviously don't need NAT.
NAT is stateful, at least in the most common configuration. Static NAT is not something a home user needs to worry about.
Honestly, if you have NAT you almost certainly have a firewall because NAT is nearly always implemented as part of the firewall. It may not be a properly configured firewall, but the functionality is there.
Honestly, if you have NAT you almost certainly have a firewall because NAT is nearly always implemented as part of the firewall. It may not be a properly configured firewall, but the functionality is there.
If send a packet destined for "10.10.10.11" to "71.28.10.10", your router would happily figure out "what interface do I forward 10.10.10.11 to" and it would happily send it to the connected device, because NAT is not a firewall. There is no rule stating that "packets destined for 10.10.10.11 on eth0 should not be forwarded to eth1". That's what a firewall is for.
And yes, your little router, is actually a router. It will dutifully take packets from one interface, look at it's routing table and figure where to spit it out. That's what it is supposed to do, NAT just adds a rule that says if a packet comes from eth1 and is destined for 0.0.0.0/0 (default route) out interface eth0 then we (the router) want to masquerade as if we are the source of that packet, so that this entire network looks as if it is coming from one single IP.
No firewall involved, and packets arriving on eth0 are going to get routed to eth1 all the same, since after all, we are a faithful little router.
This is how routing has worked since the dawn of time. Adding a firewall means we can say "but I should never see traffic destined to 10.10.10.0/24 on eth0, so drop it".
---
Either way, NAT may be part of the firewall but there is no requirement for it to be part of the firewall. When it comes to IPv6, just like IPv4, a firewall is required, and as soon as you have a firewall that blocks incoming traffic, then NAT becomes meaningless.
And yes, your little router, is actually a router. It will dutifully take packets from one interface, look at it's routing table and figure where to spit it out. That's what it is supposed to do, NAT just adds a rule that says if a packet comes from eth1 and is destined for 0.0.0.0/0 (default route) out interface eth0 then we (the router) want to masquerade as if we are the source of that packet, so that this entire network looks as if it is coming from one single IP.
No firewall involved, and packets arriving on eth0 are going to get routed to eth1 all the same, since after all, we are a faithful little router.
This is how routing has worked since the dawn of time. Adding a firewall means we can say "but I should never see traffic destined to 10.10.10.0/24 on eth0, so drop it".
---
Either way, NAT may be part of the firewall but there is no requirement for it to be part of the firewall. When it comes to IPv6, just like IPv4, a firewall is required, and as soon as you have a firewall that blocks incoming traffic, then NAT becomes meaningless.
So if I'm understanding correctly, by spoofing the destination IP you can effectively manipulate the routing pathway and bypass the NAT to communicate with devices on the LAN?
There is no "spoofing" or "manipulation" or "bypassing", it's simply sending a packet to the address and a router doing what a router does, in a use case that simply doesn't involve the NAT.
The idea that NAT prevents inbound connections is simply a myth believed by tons of people who have no clue how IP works. It simply doesn't. So you don't need to do any "spoofing" or "manipulation" to "bypass" something that NAT simply doesn't do.
You might as well say that you can bypass a P.O. box by spoofing the destination address and thus effectively manipulating the snail mail routing. No, it's simply the case that you can address letters to street addresses and the postal service will deliver them to the address written on the envelope. Your mistake is in the completely baseless assumption that a P.O. box is supposed to prevent letters from being delivered to your street address.
The idea that NAT prevents inbound connections is simply a myth believed by tons of people who have no clue how IP works. It simply doesn't. So you don't need to do any "spoofing" or "manipulation" to "bypass" something that NAT simply doesn't do.
You might as well say that you can bypass a P.O. box by spoofing the destination address and thus effectively manipulating the snail mail routing. No, it's simply the case that you can address letters to street addresses and the postal service will deliver them to the address written on the envelope. Your mistake is in the completely baseless assumption that a P.O. box is supposed to prevent letters from being delivered to your street address.
Then why is it necessary to Port Forward / have an Open NAT in order to connect remotely in most cases such as online gaming or ssh?
Because the internet generally does not route RFC1918 addresses, and in particular not to you. But that is not a security feature, as there is no guarantee that noone will ever send such packets to you, it's simply that those addresses are not (uniquely) allocated to you, and therefore, your ISP doesn't know to route them to you. Also, many ISPs won't accept routes for RFC1918 addresses from other ISPs because it is well-known that they are not allocated to any particular party, and anyone announcing them risks being flooded with packets leaking from local networks that cannot usefully be delivered anyhow.
But nothing prevents your ISP from sending you packets addressed to RFC1918 addresses. Or anyone who happens to have compromised your ISP('s router), for that matter. Also, it happens that ISPs fail to properly isolate customers, and neighbours who are customers of the same ISP can directly send layer 2 packets to your router. Or it happens that ISPs forget to disable routing protocols on customer-facing ports, and if your router is misconfigured as well, it might be announcing your RFC1918 prefix to your ISP, which then would start routing packets from its other customers addressed to that prefix to you (probably not from other ISPs, as BGP peers usually would drop such routes--but even that is not guaranteed).
It's just a convention to not route RFC1918 addresses over the public internet for the simple reason that they are well-known to not belong to anyone in particular, and in any case your ISP generally wouldn't know who of the many users of those addresses to deliver packets to. I guess that's a bit analogous to writing "to Joe by the big tree" on an envelope and dropping it in the mailbox. That is not a clear, unambiguous address, belonging to one particular person, so chances are the postal service won't know what to do with it and it won't ever arrive. But that doesn't mean there is a guarantee that it won't arrive. Some postal worker might happen to know Joe and that he is known in some circles as Joe by the big tree, and the letter might arrive after all.
But nothing prevents your ISP from sending you packets addressed to RFC1918 addresses. Or anyone who happens to have compromised your ISP('s router), for that matter. Also, it happens that ISPs fail to properly isolate customers, and neighbours who are customers of the same ISP can directly send layer 2 packets to your router. Or it happens that ISPs forget to disable routing protocols on customer-facing ports, and if your router is misconfigured as well, it might be announcing your RFC1918 prefix to your ISP, which then would start routing packets from its other customers addressed to that prefix to you (probably not from other ISPs, as BGP peers usually would drop such routes--but even that is not guaranteed).
It's just a convention to not route RFC1918 addresses over the public internet for the simple reason that they are well-known to not belong to anyone in particular, and in any case your ISP generally wouldn't know who of the many users of those addresses to deliver packets to. I guess that's a bit analogous to writing "to Joe by the big tree" on an envelope and dropping it in the mailbox. That is not a clear, unambiguous address, belonging to one particular person, so chances are the postal service won't know what to do with it and it won't ever arrive. But that doesn't mean there is a guarantee that it won't arrive. Some postal worker might happen to know Joe and that he is known in some circles as Joe by the big tree, and the letter might arrive after all.
That is PAT not NAT. Port numbers are a scarce resource and there are various ways to allocate them. This may be a 1:1 or 1:random or n:n static range or n:n random.
A stateful PAT would inspect packets to set up port translation and these things used to have lots of bugs and no filtering to check if the packet is from internal or external network at times.
You can often still send to the direct target port and IP if you guess or figure out the mapping. Scanning 64k numbers with packets is not that hard.
A stateful PAT would inspect packets to set up port translation and these things used to have lots of bugs and no filtering to check if the packet is from internal or external network at times.
You can often still send to the direct target port and IP if you guess or figure out the mapping. Scanning 64k numbers with packets is not that hard.
Because you can't route a packet addressed to 10.x.x.x or 192.168.x.x or other private network spaces directly over the Internet, which is the attack people are talking about here.
If you get a packet addressed to 10.10.10.11 delivered to my home over the Internet then you kind of deserve to get in.
There will never be "no firewall involved" because NAT functionality is implemented as part of the firewall in the real world. Your point that it doesn't necessarily have to be part of the firewall is academic.
There will never be "no firewall involved" because NAT functionality is implemented as part of the firewall in the real world. Your point that it doesn't necessarily have to be part of the firewall is academic.
> There will never be "no firewall involved" because NAT functionality is implemented as part of the firewall in the real world.
So, you are telling me that, say, if you configure NAT on a Linux kernel, that necessarily implies some sort of firewall? (hint: it doesn't)
So, you are telling me that, say, if you configure NAT on a Linux kernel, that necessarily implies some sort of firewall? (hint: it doesn't)
Hint: It does.
NAT is part of the netfilter module. Pull netfilter out of the kernel and you don't get NAT. It's even configured using the iptables command.
You can configure your firewall to do no filtering, but your packets are still going to be processed by the firewall module. You will still get automatic protections like reverse path filtering for example.
In practice when someone who doesn't know a damn thing about networking clicks the "do NAT" button on their router they're going to at least get basic protections like "No RFC 1918 destinations in on external interface" by default unless their vendor is pants on head. There's obviously more room to screw up if you're manually typing in iptables commands at a bash prompt, but at that point you should know better.
NAT is part of the netfilter module. Pull netfilter out of the kernel and you don't get NAT. It's even configured using the iptables command.
You can configure your firewall to do no filtering, but your packets are still going to be processed by the firewall module. You will still get automatic protections like reverse path filtering for example.
In practice when someone who doesn't know a damn thing about networking clicks the "do NAT" button on their router they're going to at least get basic protections like "No RFC 1918 destinations in on external interface" by default unless their vendor is pants on head. There's obviously more room to screw up if you're manually typing in iptables commands at a bash prompt, but at that point you should know better.
> Hint: It does.
So, if I configure NAT, that prevents inbound connections?
Or are you saying that it implies a firewall that won't filter a single packet, i.e., a firewall that is functionally equivalent to no firewall at all, but that you insist on calling a firewall because it makes you "win the argument" while not contributing anything useful to the discussion?
Yeah, and next I'll be selling cars with an air bag that isn't hooked up. I guarantee you, your head will be processed by an air bag module when you have an accident. So, who are you to claim that my cars don't have an airbag!
So, if I configure NAT, that prevents inbound connections?
Or are you saying that it implies a firewall that won't filter a single packet, i.e., a firewall that is functionally equivalent to no firewall at all, but that you insist on calling a firewall because it makes you "win the argument" while not contributing anything useful to the discussion?
Yeah, and next I'll be selling cars with an air bag that isn't hooked up. I guarantee you, your head will be processed by an air bag module when you have an accident. So, who are you to claim that my cars don't have an airbag!
> NAT is stateful, at least in the most common configuration.
Which doesn't make it a firewall, just stateful NAT.
> Honestly, if you have NAT you almost certainly have a firewall because NAT is nearly always implemented as part of the firewall. It may not be a properly configured firewall, but the functionality is there.
Not sure what your point is here?!
That a NAT without a firewall would do the job just as well? (no, it wouldn't)
That there is some implementation overlap between the code you need for a stateful NAT and a stateful firewall? (yeah, so what?)
That stateful NAT being implemented and configured on a device guarantees there is also a working stateful firewall? (no, it obviously doesn't)
That there is some security benefit to having the NAT in addition to the stateful firewall? (no, there isn't)
For the user, it's completely irrelevant whether "the functionality is there" if it isn't actually set up to do the job the user requires. And NAT only obfuscates things, as is demonstrated by this very thread: Without NAT, it is trivial to check whether there is a stateful packet filter or not. With NAT, it's difficult to test, and most people obviously aren't even aware that there would be something to test because they think NAT implies a stateful firewall.
Which doesn't make it a firewall, just stateful NAT.
> Honestly, if you have NAT you almost certainly have a firewall because NAT is nearly always implemented as part of the firewall. It may not be a properly configured firewall, but the functionality is there.
Not sure what your point is here?!
That a NAT without a firewall would do the job just as well? (no, it wouldn't)
That there is some implementation overlap between the code you need for a stateful NAT and a stateful firewall? (yeah, so what?)
That stateful NAT being implemented and configured on a device guarantees there is also a working stateful firewall? (no, it obviously doesn't)
That there is some security benefit to having the NAT in addition to the stateful firewall? (no, there isn't)
For the user, it's completely irrelevant whether "the functionality is there" if it isn't actually set up to do the job the user requires. And NAT only obfuscates things, as is demonstrated by this very thread: Without NAT, it is trivial to check whether there is a stateful packet filter or not. With NAT, it's difficult to test, and most people obviously aren't even aware that there would be something to test because they think NAT implies a stateful firewall.
The point is that when you have NAT you already have a firewall because they come as a package. For practical purposes complaining that "NAT ins't a firewall" is silly because when you have NAT you always have a firewall too.
In the real world SOHO routers that implement NAT also include the absolute bare bones firewall functionality of "block private addresses on the WAN port". Hand wringing over "but if someone convinces my ISP to route a 192.168.x.x packet to my home it could bypass NAT!" is pointless.
In the real world SOHO routers that implement NAT also include the absolute bare bones firewall functionality of "block private addresses on the WAN port". Hand wringing over "but if someone convinces my ISP to route a 192.168.x.x packet to my home it could bypass NAT!" is pointless.
You are simply missing the point of the discussion.
Even if NAT always implied a firewall, that doesn't change that the NAT is not the thing that is keeping you safe. The firewall is what is keeping you safe. That's why you don't need the NAT to stay safe. You can just drop the NAT and keep the firewall and everything will be fine.
You might as well say that a car radio keeps you safe in an accident. Because a car with a car radio for practical purposes nowadays comes with an air bag! Yeah, sure it does, but it's just nonsensical to conclude from that that the car radio is what is keeping you safe. It's not that buying a car with a car radio isn't a way to keep you safe in an accident, it's just that the car radio is completely irrelevant to the problem. Buy the same car without a car radio and you will be just as safe.
Even if NAT always implied a firewall, that doesn't change that the NAT is not the thing that is keeping you safe. The firewall is what is keeping you safe. That's why you don't need the NAT to stay safe. You can just drop the NAT and keep the firewall and everything will be fine.
You might as well say that a car radio keeps you safe in an accident. Because a car with a car radio for practical purposes nowadays comes with an air bag! Yeah, sure it does, but it's just nonsensical to conclude from that that the car radio is what is keeping you safe. It's not that buying a car with a car radio isn't a way to keep you safe in an accident, it's just that the car radio is completely irrelevant to the problem. Buy the same car without a car radio and you will be just as safe.
What you are talking about is PAT. PAT unlike NAT requires firewall to operate.
What he pointed out is that if you have a firewall you can provide security through that, you don't need NAT or PAT.
In fact having just a firewall is safer, because it is simpler
What he pointed out is that if you have a firewall you can provide security through that, you don't need NAT or PAT.
In fact having just a firewall is safer, because it is simpler
True, although ipv6 adds privacy concern as each device can now be identified by its IP, you need to make sure your OSes are configured to request different IP on each renegotiation.
Stop acting like a NAT is going to save you. Protip: it isn't.
You need proper firewalls, NAT, and physical network design. It's an entire security package, you don't just slap NAT on it and call it done.
You need proper firewalls, NAT, and physical network design. It's an entire security package, you don't just slap NAT on it and call it done.
Could you help me understand some of the weaknesses of NAT vs a firewall? I was under the impression they were almost synonymous
With just NAT someone who is on same L2 domain as you could you packet that has private IP address in the destination address. If there's no firewall (i.e. no deny rules for packets coming from outside interface directed to private addresses or more commonly just blanket deny for all non-established/related packets), router would happily forward the packet. The return packet may end up being weird (router may or may not change the source IP & port), but the attacker would be able to talk to the given host.
Firewalls may not even have NAT functionality. They are used to figure decide if packet coming from interface with some flags (source, destination, ip, protocol, port, tcp flags etc.) is allowed to be passed to another interface. These days virtually all routers have at least basic firewall support & firewalls have at least basic NAT support.
Firewalls may not even have NAT functionality. They are used to figure decide if packet coming from interface with some flags (source, destination, ip, protocol, port, tcp flags etc.) is allowed to be passed to another interface. These days virtually all routers have at least basic firewall support & firewalls have at least basic NAT support.
I tried to explain it here in case someone wants a little more information with some "real" examples:
https://news.ycombinator.com/edit?id=17141287
https://news.ycombinator.com/edit?id=17141287
NAT does not prevent inbound connections, and noone is giving devices "publicly reachable IP address". The only thing a sensible IPv6 setup does is that it gives every device a unique address. And the stateful firewall that you also need with IPv4 to prevent inbound connections works just as well with IPv6, so no need to add a pile of NAT crap.
> NAT does not prevent inbound connections
True, but it also doesn't route them anywhere unless you've explicitly configured it to OR there was outbound traffic on that 5-tuple recently, so it's also wrong. The NAT functionality drops the errant packet on the floor just as much as a traditional firewall.
Note: this is referring to dynamic NAT, which is the kind of NAT that every SOHO router supports by default out of the box and is the only kind normal users ever use.
True, but it also doesn't route them anywhere unless you've explicitly configured it to OR there was outbound traffic on that 5-tuple recently, so it's also wrong. The NAT functionality drops the errant packet on the floor just as much as a traditional firewall.
Note: this is referring to dynamic NAT, which is the kind of NAT that every SOHO router supports by default out of the box and is the only kind normal users ever use.
> True, but it also doesn't route them anywhere unless you've explicitly configured it to OR there was outbound traffic on that 5-tuple recently, so it's also wrong.
No, what you are describing is a stateful firewall. Also, neither a NAT nor a firewall route anything, that's what a router is for.
> The NAT functionality drops the errant packet on the floor just as much as a traditional firewall.
NAT does not drop anything. NAT translates. Hence, "network address translation". And it's not an errant packet. It's simply a packet addressed to an address reachable on one of the interfaces attached to the router, and not matching any NAT rules that would initiate translation of a connection nor any existing tracking state of a previously seen connection where return packets need to be translated. Packets that don't fit in either of those categories are simply left untouched by a NAT. And the router the NAT is running on will then just forward them as any IP router would do. That is, unless there is a stateful firewall present as well. In which case you still don't need the NAT to use it.
No, what you are describing is a stateful firewall. Also, neither a NAT nor a firewall route anything, that's what a router is for.
> The NAT functionality drops the errant packet on the floor just as much as a traditional firewall.
NAT does not drop anything. NAT translates. Hence, "network address translation". And it's not an errant packet. It's simply a packet addressed to an address reachable on one of the interfaces attached to the router, and not matching any NAT rules that would initiate translation of a connection nor any existing tracking state of a previously seen connection where return packets need to be translated. Packets that don't fit in either of those categories are simply left untouched by a NAT. And the router the NAT is running on will then just forward them as any IP router would do. That is, unless there is a stateful firewall present as well. In which case you still don't need the NAT to use it.
NAT doesn't prevent someone from sending a packet to your external interface (eth0) saying "this is destined for 10.10.10.9" which happens to be a 10.10.10.0/24 that you have assigned to eth1.
Routers gonna route.
Firewall is the one that would block that by saying "Sorry, but I shouldn't ever see packets destined for 10.10.10.0/24 on my eth0 interface".
Routers gonna route.
Firewall is the one that would block that by saying "Sorry, but I shouldn't ever see packets destined for 10.10.10.0/24 on my eth0 interface".
Yes, but if someone has managed to convince the internet to route a packet addressed to 10.10.10.0/24 to your subnet then you've got bigger issues.
Also, every competently designed router has a rule that blocks that address range on the external interface.
The whole NAT isn't a firewall meme is pendantry at its finest since NAT is implemented as part of the firewall.
Also, every competently designed router has a rule that blocks that address range on the external interface.
The whole NAT isn't a firewall meme is pendantry at its finest since NAT is implemented as part of the firewall.
> Yes, but if someone has managed to convince the internet to route a packet addressed to 10.10.10.0/24 to your subnet then you've got bigger issues.
It's not necessarily the whole internet. If someone wants to compromise you, they only need to gain access to a router at your ISP. Also, ISPs do misconfigure stuff and allow direct layer 2 communication from neighbours, or accept routing protocol advertisements from customer-facing ports. Whether you like it or not, those things just happen, and a well-secured network has a firewall that makes sure it is completely inconsequential to you, so, no, you actually don't have "bigger issues", you have an absolute non-issue.
> Also, every competently designed router has a rule that blocks that address range on the external interface.
So, like those with hard-coded default passwords and shell injection vulnerabilities in the web admin interface? Is that the kind of competently designed router that you are talking about?
Noone claims that a properly configured firewall isn't part of a "competently designed router". The question is how many of the routers out there are competently designed. If anything, this idea of "NAT implies a firewall" is one reason why border gateways end up "incompetently designed", because it doesn't, but if you believe that when designing such a device (be it for mass production or as an individual manual configuration), chances are you'll end up with a completely unprotected network.
> The whole NAT isn't a firewall meme is pendantry at its finest since NAT is implemented as part of the firewall.
That is like saying that saying "Word isn't Excel" is pedantry because Word is implemented as part of Excel. It's just nonsense. Both share some common technical foundation, and even code for common functionality. That doesn't make one "implemented as part of the other".
It's not necessarily the whole internet. If someone wants to compromise you, they only need to gain access to a router at your ISP. Also, ISPs do misconfigure stuff and allow direct layer 2 communication from neighbours, or accept routing protocol advertisements from customer-facing ports. Whether you like it or not, those things just happen, and a well-secured network has a firewall that makes sure it is completely inconsequential to you, so, no, you actually don't have "bigger issues", you have an absolute non-issue.
> Also, every competently designed router has a rule that blocks that address range on the external interface.
So, like those with hard-coded default passwords and shell injection vulnerabilities in the web admin interface? Is that the kind of competently designed router that you are talking about?
Noone claims that a properly configured firewall isn't part of a "competently designed router". The question is how many of the routers out there are competently designed. If anything, this idea of "NAT implies a firewall" is one reason why border gateways end up "incompetently designed", because it doesn't, but if you believe that when designing such a device (be it for mass production or as an individual manual configuration), chances are you'll end up with a completely unprotected network.
> The whole NAT isn't a firewall meme is pendantry at its finest since NAT is implemented as part of the firewall.
That is like saying that saying "Word isn't Excel" is pedantry because Word is implemented as part of Excel. It's just nonsense. Both share some common technical foundation, and even code for common functionality. That doesn't make one "implemented as part of the other".
Most SOHO routers are built using either a Linux kernel where it is part of the netfilter (firewall) module or VxWorks where it is part of the Firewall subsystem.
It's like saying the chart builder in Excel isn't part of Excel because it's not the spreadsheet editor.
It's like saying the chart builder in Excel isn't part of Excel because it's not the spreadsheet editor.
> Most SOHO routers are built using either a Linux kernel where it is part of the netfilter (firewall) module or VxWorks where it is part of the Firewall subsystem.
Which is just completely irrelevant to the question of whether the device has a firewall, see my inactive air bag analogy in my reply elsewhere in this thread.
> It's like saying the chart builder in Excel isn't part of Excel because it's not the spreadsheet editor.
Except that you are arguing for the idea that a chart builder necessarily implies a spreadsheet program and that therefore you need a chart builder, because otherwise you can't have a spreadsheet problem.
Which is just completely irrelevant to the question of whether the device has a firewall, see my inactive air bag analogy in my reply elsewhere in this thread.
> It's like saying the chart builder in Excel isn't part of Excel because it's not the spreadsheet editor.
Except that you are arguing for the idea that a chart builder necessarily implies a spreadsheet program and that therefore you need a chart builder, because otherwise you can't have a spreadsheet problem.
There are several address scopes available. You don't need to use globally unique addresses, if you don't like. This seems to be very common misunderstanding.
* https://en.wikipedia.org/wiki/IPv6_address#Address_scopes
* https://en.wikipedia.org/wiki/IPv6_address#Address_scopes
Not really. To access the Internet you either need to use global addresses or you need "illegal" NAT66. And consumer ISPs are definitely giving people global IPv6 addresses by default.
Even if the device has global unique address for accessing Internet, it doesn't mean that you would need to bind the services you're providing to that address. It's totally normal with IPv6 for any device to have multiple addresses, which have different scopes. If you're using privacy addressing you probably have already several addresses in use, then you got the local addresses and you might as well configure ULA for local communication as I've done for services which I don't want to be Internet accessible.
IPv6 out of the box is not able to safely cope with multiple links to the rest of the internet. For example, you have a 100MB leased line and four FTTC connections to your site - which I happen to have. Each of those links has a IPv6 prefix and for me those are all /56. So far so good - I've got a lot of IPv6 addresses.
So, I use SLAAC to dole out five lots of addresses to my systems. There is no way for my systems to know which links are up or even to decide which ones would be favourite unless I turn everyone into a "router lite" via say OSPF. So I have to use my router to do that and use NPT to do NAT by another name.
IPv6 out of the box does not work properly with multiple links to the internet.
I really do feel quite ashamed when I say that I think IPv6 is badly broken. I deploy the bloody thing because its all we have. I remember that back in the seventies that this internet thing was touted as being able to route around problems due to nuclear attack. That was IPv4. Which is shit.
We have been sold out big style, several times. IPv6 can't cope with multi link without NAT via a different name and telephony has no useful ENUM.
Your internet is not run by genial Engineers. It's fucked up by entrenched monopolies, worldwide.