More accurately, v6 needs to be ubiquitous because it's actually designed to be used for a global production network, and legacy ip needs to be relegated into a niche for retro enthusiasts.

It is legacy ip which is far more dangerous in the hands of someone who doesn't know what they're doing.

Speaking of the XSRF, here's a PoC:

This works on the default router provided by the ISP here, telnet.cgi accepts an arbitrary command and executes it as root so you can easily do something more sinister than reboot the router, the isp has many thousands of customers and most of them will be using the default supplied router, and this router vendor sells to other providers as well with only cosmetic branding changes to the firmware.
I see this exact model of router all over the place in small businesses.

This attack works because the internal address is easily predictable, and that's directly caused by nat - this attack is not practical against v6 because the address is not predictable and the range of addresses it could have is too large to brute force.

No, v6 needs to be ubiquitous. Having it only in the hands of those who understand enough to want it means that it won't be widely enabled, and thus becomes useless - eg if you travel somewhere you will constantly find yourself stuck on legacy links and thus will still be stuck with the cost/headaches of having to make your own systems reachable from such legacy networks.

Again all the more reason for more widespread use, so the bugs get discovered and pressure is applied to have them fixed.

Only thats already the case.
A lot of mobile networks have fully open v6, i can name several i have personal experience with and this has not resulted in compromised devices.
I'm aware of several ISPs that ship routers which are fully open by default, and 99% of users won't ever change those settings or even know how. This has not resulted in an increase of infected machines as modern client devices are set up to handle this, and random embedded devices are not practical to discover in the vast address space v6 provides.

I've seen many devices exploited via XSRF (see previous post), but this depends on a predictable address which nat provides, and is not practical with globally routable addressing.

That's not to say things couldn't be improved, but a default blanket "deny all inbound, allow all outbound" is stupid. This breaks p2p and is useless against today's threat profiles.
We need ISPs following the standards for v6 implementation (ie delegating a /56 prefix to users), and consumer equipment which creates separate isolated networks for different purposes.
For instance if i receive 2001:db8:100:100::/56 i would set up:

2001:db8:100:101::/64 - personal devices like laptops and phones
2001:db8:100:102::/64 - work from home (the IT dept has access to my work laptop, so i need to keep it separate from my personal things)
2001:db8:100:103::/64 - guests who visit my home (cell service sucks where i live so people are cut off if i dont give them guest wifi)
2001:db8:100:104::/64 - untrusted iot devices where both inbound and outbound is tightly controlled and restricted to specific addresses
2001:db8:100:105::/64 - kids, etc
2001:db8:100:106::/64 - voip phones where traffic is only allowed to/from the external voip provider (sip doesnt play well with nat, and a given provider can have a single v6 block vs fragmented legacy blocks so the acl is much cleaner)
2001:db8:100:107::/64 - games consoles (the xbox does p2p over v6 for certain multiplayer games)
2001:db8:100:108::/64 - cctv (i use poe cameras, so there is a risk of a physical threat actor disconnecting the cable from an external camera and trying to connect to it, so this needs to be isolated in its own vlan)

That way if anything suspicious happens and gets reported, i know immediately which vlan/ssid it came from, if you're stuck with nat then any external report is going to have the nat gateway address and while the capability for multiple ssids/vlans is realistic and already supported by some consumer hardware, the ability to log nat traffic and trace a specific activity that happened a few days earlier back to its internal address is simply not practicel with consumer equipment and would cost a significant amount to implement as you'd need to add storage to hold the logs.

In fact aside from v6, the ability to have multiple vlans/ssids is important for other reasons, such as having to operate weaker wifi security for legacy devices - eg various devices don't support wpa3 yet, and nintendo kept wep alive for many years because some of their handheld consoles didn't support anything else. What's needed is for consumer routers to support and encourage this, and make it easy to assign different access policies to different networks with a set of default profiles available - eg allow all, allow nothing, only allow one-way access from one of the other networks.

Many of them have a "dmz ip" feature which automatically forwards all ports to a specific host, its very easy to flip this on without understanding what it does.
There are also thing like UPNP that can result in arbitrary ports being opened.
Don't forget slipstream attacks either (google this).

If you're not aware if this then you've almost certainly never used v6 or managed an environment with it active, so your knowledge on the subject is extremely questionable. This in itself is dangerous because v6 is enabled by default on most things but a lack of awareness will lead to security risks.

That doesn't mean you expect to have every individual connection logged, or that the university would want to cover the cost of collecting and storing those logs.

Once you do have such logs (eg legislation in several countries requires operators to keep such logs if they're using CGNAT) then there's a commercial incentive to try and recoup some of those costs by data mining the logs and selling the data.

The rules also tend to be relaxed somewhat for residence halls - as people live there and don't generally study 24/7. Maybe porn or warez would still be frowned upon, but personal communication, gaming, legal streaming etc would generally be allowed in the residence halls outside of study hours even if not on the main campus.

Indeed, but this is a somewhat different risk vector.

These embedded devices are almost always compromised over legacy IP, despite the fact that many of them do support v6. Discovering them over v6 is hard.
Try it, put two identical insecure devices online - one via v6 and one via legacy ip, see which one gets compromised.

You can also compromise devices behind NAT via XSRF in many cases because the address space is predictable - for instance i know that the ISP here provides a router that's exploitable via HTTP and i know the default address space they use, so if i can entice a user to visit a site under my control i can put an image tag which points to http://192.168.1.1/xxxx... and execute arbitrary commands on their router.
Theoretically i could do the same with v6, and i can successfully PoC this against my own device because i know its address, but weaponizing the attack against someone else i would need to:
1) get their prefix - this is actually possible based on where they connect from so i know the first 64 bits of the address.
2) guess the second 64 bits - now this i haven't found a practical way to do as the second 64 bits of the address are random.

Plus these devices tend not to hold data that's important to the users, so users are less concerned about them. If their workstation gets compromised and a keylogger gets their banking creds thats a BIG problem, if a random IoT device gets popped and starts spewing out spam or ddos traffic thats the isp's problem and the user can just pull the plug on it if the traffic is heavy enough to slow their other stuff down.

End user devices these days are not affected by attacks via inbound traffic, so NAT or firewall rules which block inbound don't help them and actually only serve to hinder p2p.
The alternative to p2p is relying on a third party server, which has privacy, latency, performance and cost considerations.

This is also why it's recommended to provide a /56 of v6 space to home users, so you can create multiple isolated networks to segregate these devices you don't trust.

Emule was not the infection vector, people/bots would bulk scan legacy address space. A vulnerable machine would get infected even if it never ran emule or any other p2p software.

You could connect a default install to a routable legacy IP and it would be compromised before the installation had even finished, without running any p2p software.

If they also happened to download and execute malware from the p2p network (and this most certainly did happen at the time too) then that's an entirely different scenario that wouldn't be stopped by NAT or a proper firewall configured only to block inbound.

As they say: Correlation does not imply causation
Those machines with exposed vulnerable services over legacy IP would have got infected wether they ran p2p software or not.

Literally noone has ever done that.
For legacy IP you just scan sequential address blocks and can scan all allocated address space pretty quickly.

You would only need to attack clients that access your webserver first if you're using v6 where scanning sequential address space is not practical, but modern operating systems don't expose any listening ports by default so that would be pointless anyway.

What actually happens, is attackers deliver exploits over the inbound connection that the target has already made to a hostile web server - try to exploit vulnerabilities in their browser or its plugins, or in their media player since they're downloading video files, or just serve up executables directly and social engineer the user into opening them (eg by saying you need this codec or player application to play the video).
All of these attack vectors work irrespective of wether the user is behind a firewall or not, their firewall clearly allowed the outbound connection in order for them to access your website in the first place and you can operate a remote control channel which works via outbound connections too.

These are real world attack vectors.

An incompetent firewall admin can mess up NAT just fine, and is more likely to due to the added complexity. A simple allow/deny firewall with routable addresses both sides is much easier.

Because NAT is more complex, the chance of bugs existing is increased. If bugs exist then they can be exploited regardless.

You still expose the IP of the NAT gateway.
v6 traffic by default uses random privacy addressing for outbound connections, so outbound traffic originates from random addresses

A VPN does not have to use NAT, that's another side effect of the shortage of legacy IP. There are plenty of VPNs and other tunnels which give you public routable v6 addresses, some public vpn providers will also let you rent a non-nat legacy address (for an extra fee).

Back in the 2000s you were more likely to have been giving public legacy IP to users, so it's easy to look at which port had the lease.

With NAT you have much more of a headache because you need to log all the state translations, and you also need to know the src/dst ports. Because of NAT an external party is only going to see the address of the firewall, you have to figure out the internal address yourself which means keeping a lot more logs. This has both cost and privacy implications vs just logging address assignments.

The ISP doesn't need to do anything. On a lot of connections the WAN address of customers routers is in a shared subnet, so all another customer needs to do is add a route to your RFC1918 address space via the WAN address of your router.

For instance here the fibre connection is using DHCP and assigns a legacy IP 100.96.174.243/18 (yes CGNAT). Other customers in the same region are also within that subnet, and i can see the WAN addresses of their routers as well as get ARP responses from them.
If i manually add a route on my gateway to 192.168.1.0/24 via 100.96.174.242, i can start scanning 192.168.1.0/24 which is the default LAN address range for the default router provided by this ISP. These default supplied routers absolutely do allow this traffic because i've tested it myself.

Some firewalls have explicit options for this - eg "Block Bogons" in pfsense.

I can do the same with v6 of course, the WAN interfaces of the other customers are also in the same /64 as my router, but there's no need to manually add a route since a public route already exists. But v6 traffic will be treated exactly the same wether it comes from an adjacent user or from the other side of the planet.

So the basic point is that NAT adds complexity and creates corner cases like this, you need to be aware of this possibility and test if it applies to the topology of your specific ISP and then mitigate against it - but most users won't and will just falsely assume that NAT protects them.
With v6 it's more straight forward - you either allow external traffic or you don't, and you can verify this yourself very easily using publicly available tools rather than having to rely on a cooperative neighbor.

Of course none of this considers that the threat landscape has changed. Modern consumer devices don't have complex listening services exposed by default like WinXP did, and modern devices do not sit in one place always behind the same firewall - we live in a mobile world where people use portable devices and frequently connect them to arbitrary wifi or cellular data networks. Modern devices are prepared for the scenario that they will be connected to a public network with no separate firewall between the device and potentially hostile/infected users.
Current threats are not based on attackers making inbound connections to your device, they are based around exploiting outbound connections that you've made from your device - and a default NAT or default unrestricted outbound firewall does absolutely nothing to counter this threat vector.

True, it's just kicking the can down the road - partially and temporarily solves one problem, while creating new more serious ones.

Many large companies have serious problems with overlapping address space, squatting on address space that isn't theirs and was previously unallocated - for instance one company i've worked with recently used 20.x address space because "its was unused" and they had run out of 10.x, only now a lot of the 20.x space is owned by Microsoft and used for Azure leaving this company with random Azure-hosted resources they cannot reach because 20.x gets routed internally.

But my comment was in reference to the previous comment:

In practice today you can't use legacy IP as it was intended, you're forced to use NAT unless you have a huge budget.

You could just have easily retained the public IPs, while putting a firewall in front of them. NAT was just added complexity providing no benefit other than reducing the number of legacy addresses required.

By hiding vulnerable machines behind a firewall you've not actually solved the problem, as those machines will become instantly infected if someone introduces a single infected machine behind the firewall.

In these days of mobile devices and wifi it is actually FAR more common for this to happen - totally unrelated devices find themselves on the same public wifi network. All it takes is for one employee to travel somewhere and connect to public wifi where an already infected machine is, then bring his laptop back to the office. A public wifi might have NAT for outside access for cost reasons, but that doesn't prevent other users of the same network from connecting to each other. It also doesn't prevent users from opening arbitrary ports via UPNP, or tunneling to outside networks and thus providing a route inside etc. If you're connecting to someone else's wifi you have absolutely no control over what the network manager does, or what the other users do.

The reason worms don't propagate in this way so commonly is not down to NAT, it's due to more sensible defaults (eg windows firewall enabled by default).

Nowadays most end user malware does not rely on inbound connections, it exploits outbound connections made by the user (eg phishing, browser exploits etc). There is still malware which makes inbound connections but it tends to target servers (which by their very nature need to have services open) and embedded devices. The vast majority of this kind of malware exclusively uses legacy IP.

Meanwhile this method of propagation is not actually practical with v6 due to the huge address space, so even if machines were vulnerable the chance of them being discovered and exploited is extremely slim.

When doing enumeration against v6 networks you have to rely on public information such as DNS records, certificate transparency logs, or access logs if you can convince a user to access a site under your control. In the former cases you'll typically only find servers which are inherently meant to be public, and in the latter case you'll only get temporary addresses of end user devices (which as previously mentioned don't have any listening services for you to attack these days anyway, and if you already convinced a user to access your site that inbound connection is a far more useful attack vector irrespective of network configuration). If someone happens to have a random embedded device exposing default credentials on an SSH service good luck finding that device on a /64 network.

Even users who don't do self hosting do use things that benefit from p2p (voice/video calls, gaming, etc).
If self hosting was more accessible, more users would do it. There are plenty of things that you might want to have at home and access remotely - for instance CCTV and NAS appliances. Because of widespread NAT, users are steered towards cloud based services with all the privacy, security and longevity implications thereof, and you will find many stories here about breaches or shutdowns turning devices into bricks.

And even if only a few users benefit from it, v6 needs to be ubiquitous or those benefits are limited. What use is someone being able to self host via v6 if other users can't reach their site (and have no idea why they cant reach it because they get a generic error message instead of one explaining what the problem is)?

No they are completely different things designed for different purposes:

6in4 - allows tunneling v6 traffic over legacy networks, intended for testing/development rather than production deployments.
6to4 - maps a /48 of v6 space to every legacy address, deprecated
6rd - a facility for automatically setting up a v6 tunnel, intended for isps running antiquated equipment that can't support native v6, it's also a big red flag because any equipment too old to support native v6 is going to be well outside of its support window. We recently retired a bunch of old cisco equipment that's EOL, and it all had native v6 support.
nat64 - a backwards compatibility system allowing v6 native networks to reach legacy resources, cheaper and scales better than providing dual stack with nat44
teredo - a tunnel system with automatic configuration and nat traversal, because 6in4 and 6to4 were made on the assumption of users having routable legacy ip - you can blame legacy ip for this rather than v6.

Legacy IP is even more of a mess...

Multiple automated address configuration scheme doing the same thing - RARP, BOOTP, DHCP etc.
Multiple ways to handle variable MTUs - on path fragmentation, nested fragmentation, don't fragment bit, path mtu discovery.
Arbitrary subnet sizes.
No standard way to find out your public address from behind NAT - multiple kludges exist, usually relying on external third party sites.

Yes people on low incomes, and yet the ISPs serving them are faced with the additional costs of buying legacy address space *and* the additional cost of CGNAT, costs that older providers in western countries don't have. These extra costs have to be paid for by the users who are least able to afford the costs.

Plus CGNAT means that p2p doesn't work locally, pushing more burden onto expensive international transit links instead of cheap local peering.

Remember these people are poor and the big streaming services tend not to target their countries. The lack of regulation makes it quite easy to cover their cities in new fibre strung up on poles, if these users had routable addressing there could be a vibrant community of p2p torrents sharing content locally over the high speed fibre network. Instead because of CGNAT all the traffic has to trombone to another country and back so this doesn't happen, and people continue trading copied DVDs on market stalls and even retail stores.
Yes many developing countries couldn't care less about copyright, they cannot afford to pay for content and copied DVDs are sold openly in retail stores.

The CGNAT also stifles gaming in the same way - p2p gaming or self hosting would be very fast over the local fibre networks, but they have to connect to servers located in other countries which adds latency and further congests the expensive international transit links. There are also plenty of older and open source games that people could play for free on lowend hardware.

No these people assume that the services are poor and overpriced because they're in a third world country, they have no idea what legacy IP is or how it's slowing down their development but it absolutely is and that's obvious to anyone who understands the technology. That's not to say they don't face other problems, but this is one that has a clear and obvious solution.