Yes, with IPv6, there are are enough addresses that you don't need to use NAT. All IPv6 devices that are connected to the internet have global IPv6 addresses. I don't quite understand the question here, it seems to me that we're asking "but how could we possibly do this entirely mundane everyday thing?".

Not all devices connected to the Internet have globally unique IPv6 addresses, SLAAC and often DHCPv6 makes local v6 addresses. Where's the globally unique IPv6 address supposed to be coming from?

This explains it fairly well, I think:

https://thisbridgeistheroot.com/blog/dhcpv6-prefix-delegatio...

So you're talking about being assigned temporary globally unique addresses, if the network the device happens to be on at any given time happens to be set up in a certain way?

I still don't understand how this is supposed to help.

In https://news.ycombinator.com/item?id=45957048, addisonj suggested that the problem stems from the distinction from "local" and "global", and that with IPv6, you don't need that distinction.

This helps because you don't have a NAT distinguishing between "local" and "global", all devices are in the global namespace.

All the comments after that have been about solving an arbitrary and ill-defined problem with goalposts that keep shifting from globally unique addresses to DNS hostnames to permanent addresses.

How does getting a temporary globally unique IPv6 address from DHCPv6 solve any of the issues surrounding how new web technologies aren't available in "insecure contexts"?

I assumed that the suggestion was that you could assign a device a permanent IPv6 address, because I can easily imagine that as a part of a solution to the HTTPS issue. When every device has a permanent IPv6 address, and if every device is reachable through said IPv6 address, you could, in principle, also automate assigning each device a DNS record and set up SSL that way. It would be a pretty terrible solution that's way more complicated than just using a local address over HTTP, but it makes sense.

I have no idea how to even begin translating maybe getting temporary unique addresses through DHCPv6 into a solution to the HTTPS issue.

You can get a static prefix from your ISP. After you get the static prefix, it's up to your local network to make the local parts of the address static. There's no reason why your DHCP server can't give the device a static address, it's not like it's going to run out.

Then again, you don't need a static address to get a TLS certificate. You don't need an address at all! All you need is a domain name.

Some of the devices I'm talking about are running on my own residential internet connection or my sister's. Some are running on whatever corporate or residential or 4G network happens to exist where I need to interact with them. Some are running on whatever network the user has.

How does your proposed suggestion of getting a static prefix from an ISP apply to those situations? Should I start calling customers to get them to ask their ISP for a static IP address?

> Then again, you don't need a static address to get a TLS certificate. You don't need an address at all! All you need is a domain name.

I don't understand what you think this solves.