IP Fragmentation at routers was removed from the protocol for one.
Another is that it changes the way you think about IP addresses, with endpoints getting a /64 instead of a single address like you did in IPv4. This allows users to change their IP address for every connection if they want, so if you want to apply policy to them you need to apply it to the entire subnet they are on. Granted, this also happens in IPv4 if you are doing NAT, so it's not really a change for most people.
There are a few other changes to stuff like QoS to better reflect modern practice, but for the most part it's pretty similar. Also, the IP header lost its checksum, as it was basically never useful.
> Another is that it changes the way you think about IP addresses, with endpoints getting a /64 instead of a single address like you did in IPv4.
End points get /128, it's just that subnets are now /64.
That simply means that endpoints can auto-assign themselves a new /128 because--instead ofhaving only space for 2^8 hosts in the typical /24 subnet of IPv4--there is now space for 2^64 hosts, which makes it unlikely that collisions will occur.
> Another is that it changes the way you think about IP addresses,
Only if you don't have a clue of IPv4 either.
> with endpoints getting a /64 instead of a single address like you did in IPv4.
That's just wrong. And endpoint gets one address, just as with IPv4 (and can optionally assign additional addresses where address space is available, also just as with IPv4).
What gets a /64 by default is a link, like, an ethernet. Which is also exactly like in IPv4, except, of course, with IPv4 you had shorter/fewer addresses, and thus obviously also smaller prefixes/fewer addresses per link.
> This allows users to change their IP address for every connection if they want, so if you want to apply policy to them you need to apply it to the entire subnet they are on.
Which is also exactly the same as with IPv4. If your LAN has an IPv4 /24, you can also change you address for every connection.
> Granted, this also happens in IPv4 if you are doing NAT, so it's not really a change for most people.
You have it all backwards?! NAT is what makes this impossible for connections to the public internet, in that no matter how you change your RFC1918 address, you keep the same address to the outside world? But that obviously is not a property of IPv4, but of NAT.
I wasn't quite precise, because there are cases where you do DHCPv6, but as Android doesn't support it the protocol is a bit dead in the water.
SLAAC the router gives you the 64 bit prefix and the host chooses its own 64 bit host address, which can be any address not already in use. With IPv4 you are typically assigned a single IP address via DHCP. While it is true that you are free to ignore the DHCP address assigned to your host and select something else on the same subnet, this is not typical. With SLAAC however it is the norm for the host to figure out its own address, and to leverage the enormous IP space available in IPv6 to change up their source address at will.
Filtering individual hosts by IP has always been leaky, but IPv6 makes it more or less impossible. You have to filter by subnet.
IPv6 does have some braindamage. SLAAC didn't have a way to communicate the local DNS server address to hosts, nor a way for hosts to update the DNS with their selected addresses and hostnames. This is something that has just worked in DHCP for decades and was completely ignored by the IETF. There was some handwaving about mDNS and anycasting but the actual protocol for doing the updates was never nailed down and it ignored the fact that multicast on wireless networks has always been fragile and plagued by hardware/driver issues.
> I wasn't quite precise, because there are cases where you do DHCPv6, but as Android doesn't support it the protocol is a bit dead in the water.
Arguably, it's alive and well for the use case where it actually makes sense: For prefix delegation.
> With IPv4 you are typically assigned a single IP address via DHCP.
Well, sure, and with IPv6 you are "typically assigned a single IPv6 address via SLAAC"!?
I mean, if you are talking about a controlled environment, that's not exactly difficult to achieve, by either using MAC-address based v6 addresses, or by configuring a fixed host suffix on the respective machine, just as you would configure DHCP. If you are talking about random people/devices on your network, neither case prevents them from assigning themselves whatever addresses they please.
> Filtering individual hosts by IP has always been leaky, but IPv6 makes it more or less impossible. You have to filter by subnet.
But that is what you are doing with IPv4 as well? Just because you can't see the individual addresses of individual machines, and thus have no other choice but to block the whole subnet (that is, the NAT gateway address that proxies for it), doesn't mean you aren't blocking whole subnets!?
> SLAAC didn't have a way to communicate the local DNS server address to hosts
Well, yeah, but that's been resolved, as you seem to know.
> nor a way for hosts to update the DNS with their selected addresses and hostnames.
Except it does? If you ask me, it does not make any sense for the DHCP server to update the DNS server anyway: It's the host that owns the host name and that knows where it is reachable, and also a host in principle could be getting its connectivity from anywhere, not just a particular fixed DHCP server. The host should have the credentials for updating its DNS name, should select the address to publish for inbound connections based on its local policy, and then publish that address to the DNS. It makes no sense to tightly couple naming services and connectivity: When my laptop switches from ethernet to LTE, it should just update its DNS name to point to the address it obtained from the LTE provider, and obviously that should not involve the DHCP server of the LTE provider.
> Well, sure, and with IPv6 you are "typically assigned a single IPv6 address via SLAAC"!?
Unlike DHCP, SLAAC doesn't assign specific addresses to hosts. It communicates the network prefix via periodic broadcasts, and hosts choose their own addresses within that prefix.
No, SLAAC is the name of the configuration mechanism, the network protocol that is used for SLAAC is NDP, specifically router advertisements (RA), and SLAAC assigns a specific address to a host, based on the information in the RA and local policy on the host that specifies how specifically to generate the host part of that specific address.
No, SLAAC is the name of the configuration mechanism, the network protocol that is used for SLAAC is NDP, specifically router advertisements (RA), and SLAAC assigns a specific address to a host, based on the information in the RA and local policy on the host that specifies how specifically to generate the host part of that specific address.
If someone is smart enough to hop IP addresses to avoid your firewall, surely they can come up with ways to tunnel a VPN out of your network (eg through DNS or over port 443...)
Changes to the way that DHCP works. There are now different methods if you're handing out subnets to a router, IPs to an end device or allowing devices to (automatically) self assign. And not all devices support all methods.
Every device that I saw as of 4 years ago (when I was working on edge IPv6 implementation) supported the NDP/SLAAC method of assigning IP addresses, which is the default for most leaf node use cases. It's optimized for a unidirectional transmission of information from routers to leaf nodes.
DHCPv6 is used for routers, which need to be given not just an individual address on the local interface but also a prefix that they can hand out to their clients. It's optimized for flows that require a confirmation from the client that it has accepted/reserved the configuration that it's been given.
It is technically possible to use DHCPv6 to hand out IPs to endpoints, but I have not seen any production network in the wild that does this.
Aside from what everyone else is saying about the semantics, there were also a lot of changes in the header format to make it easier to parse in hardware by ASICs. Fixed-length basic header, a single integer flag that indicates to routers when they need to parse variable-length options, a requirement that in the unlikely event they are used that those options need to be 64-bit-aligned, etc.
As long as they were breaking compatibility, all kinds of details were changed to make things easier on implementers.
There is no router advertisement/NDP/SLAAC in IPv4, so that's not a fair comparison. NDP/SLAAC has a vastly different architecture and behavior than DHCP(v4), and also deprecates other hacked-on IPv4 features (like DHCPv4 link local addresses and ARP).
