Originally it was “IPv6 is great, you don’t need dhcp”, but then it became “well you may need DHCP anyway so here’s DHCPv6”, and then that becomes necessary often enough that you can’t really point to that as a benefit of IPv6 any more.
You don’t need NAT but you need a lot of the systems complexity that NAT requires, because you have to manage two sets of addresses in various configurations. Split DNS, etc.
You’re fine if you own the address range and it isn’t provided to you dynamically with DHCP-PD, but that isn’t the case with basically 100% of residential deployments. You need to multihome to even apply as a RIR to get your own prefix.
https://lagrange.cloud/products/lir £15 one-off for an ASN and £7/y for a /48.
Then you just need to find someone to give you a BGP session. https://bgp.services
The Wikipedia explanation is flat-out wrong.
There is no functional difference between PA and PI.
Sorry, what's your point? That having both address autoconfiguration and DHCP is too complex? If so, that's has been the standardized state of the art in IPv4 since 2005 with RFC 3927, and has been non-standard actual practice with Windows and Mac since like 1998.
> ...you need a lot of the systems complexity that NAT requires...
No, all you need is a router that can do IPv6. It doesn't even have to have a firewall, which is absolutely mandatory for consumer-grade border-router NAT.
> ...Split DNS...
I don't run that. My DNS answers local queries for LAN hostnames it knows about and forwards global queries upstream. Just like nearly every consumer edge-router DNS server.
> ...DHCP-PD...
Yep. My ISP runs that on the WAN side of the router. I just do RAs on the LAN side of the router.
I don't think I've ever seen two computers communicate over a 169.254 address. Also, OS network stacks normally don't even try to get a link-local IPv4 address if they can get to a DHCP server or have a static address assigned. The RFC even recommends not using the link-local address if any other address is available. It's quite different from the way IPv6 works (as usual).
I have. Used to do it often in the dorms when the uni's DHCP server was on the fritz. Zeroconf/Avahi wasn't really a thing, so we'd use Network Neighborhood to get people's IP addresses to browse files or play on servers they were hosting or whatever. I have also (as the RFC envisions) done it when connected to ad-hoc WiFi networks, and also while directly connecting two Windows PCs. In those scenarios, I asked my peer what their IP address was, rather than bothering with going to Network Neighborhood.
> Also, OS network stacks normally don't even try to get a link-local IPv4 address if they can get to a DHCP server or have a static address assigned.
Correct. From the second paragraph of the Abstract of RFC 3927: [0]
> IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks).
> The RFC even recommends not using the link-local address if any other address is available. It's quite different from the way IPv6 works (as usual).
No, it's also recommended when using IPv6 to not use link-local addresses if any other address is available. (Both because those addresses are only link-local, and because one usually needs to put an outbound interface specifier on the address when you go to contact another host, which is pretty obnoxious.) It just happens that IPv6's address autoconfiguration has been upgraded to be useful for globally-routable addressing, too.
So, yeah, a usual mode of both IPv4 and IPv6 networks is to have autoconfigured addresses, as well as DHCP-assigned addresses. It just so happens that most of the time IPv4 addresses are not autoconfigured, and most of the time IPv6 addresses are not assigned by DHCP.
That's equivalent complexity.
With what seems to be the recommended IPv6 setup at least for client machines, the Link-local address is the only stable identifier of that machine, as the actual reputable address changes all the time. So, the machine has both a link-local and a routable IPv6 at the same time, and both are going to be used. This is still different from IPv4, where link-local addresses are, again, an obscure feature that almost no one uses.
What? ULA space is the IPv6 equivalent of RFC 1918 space. If you want a prefix you know will not change, then you go generate you a /48 and use that on your internal network(s).
Why on earth would people expect ISPs that have a "We won't give you a guaranteed-static IPv4 address." policy to have a "We will give you a guaranteed-static IPv6 prefix" policy? Thinking that way is madness.
Perhaps you're confused because you're looking at guidance for client machines, when you should be looking at guidance for customer edge routers? Check out RFC 7084, and in particular section 3 and its subsections, and section 4.3 and its subsections. [0]
> ...as the actual reputable address changes all the time
Are you talking about IPv6 address randomization? (AKA "privacy" addresses?) IF you are, then know that it's
a) Controlled by the operator of the computer, rather than the operator of the network it's connected to.
b) Optional, and SHOULD be able to be turned off by the computer operator.
c) RECOMMENDED that a stable address be generated for the machine, in addition to the random ones.
Thing c) is in part to deal with "But what if I want to put a AAAA into the local DNS?" problem, and in part to give expected-to-be-long-lived connections an address that the system knows will hang around for at least as long as the interface is up.
After all, unless you want to tear down the connections associated with it, you can't remove an address from an interface until those connections have closed. More addresses allocated to a host means more multicast groups joined for that host, which eats up resources on the local networking infrastructure... so (if you're using "privacy" addresses) you really, really wanna steer ephemeral connections to addresses that are temporary, and long-lived ones to ones that are not.
My point is very simple: you can’t say “IPv6 is simpler because there’s no DHCP” if there’s DHCP. It’s pretty obvious right?
DHCP is orthogonal to IPv6.
IPv6 deployment is simpler for many reasons. One being that at the typical end-user site you have neither v6 NAT nor v6 DHCP. Another being that you have enough address space (and we have collectively learned from the IPv4 allocation lessons how bad things can get) to have a good chance of setting things up so that routers need not do quite so much work to route v6 packets.
I have both globally-routable and ULA addresses assigned to the hosts on my LAN. The ULA addresses are in my local DNS, and I update global DNS whenever the site's global prefix changes. Aside from the fact that the global prefix changes way too frequently (like once a quarter) it works great for me.
> ...so we end up randomly generating them (and rotating them!)...
Yeah, I turn this shit off whenever I have the power to. This was a fucking stupid-ass thing to have on by default. Hella buncha ways you can be tracked that give zero shits about what your IP address is. (This is one time when I wish the Net Heads would have consulted with the Web Heads and learned about how trackers actually work.)
> NAT is here to stay, unfortunately, and so is DHCP.
Nothing wrong with doing DHCPv6 and SLAAC, or just DHCPv6. My network just uses SLAAC, but folks who need more features than that provides have another tool they can deploy. This is a good thing.
And you __can__ use NAT if you choose to, but if you're being assigned a publicly-routable prefix, there's no real reason to. Set up your border firewall to deny inbound unsolicited traffic, and set up uPNP (or similar) to hole-punch and you end up with the same security guarantees.