This is a horrible way to avoid upgrading the world to IPv6.
or
2) We admit that v6 needs to be rethought and rethink it. I understand why v6 does not just increase IP address bits from 32 to 128, but at this point I think everyone has admitted that v6 is simply too difficult for most IT departments to implement. In particular, the complexity of the new assignment schemes like prefix delegation and SLAAC needs to be paired back. Offer a minimum set of features and spin off everything else.
Reduction in scope and complexity makes it easier to implement high quality IPv6 stacks. We also need more high-quality reference implementations available for newer and underserved platforms, but that's a different subject.
SLAAC seems to introduce insane churn in the IPv6 of end user devices. SLAAC (vs DHCPv6) seems to struggle in fully configuring an end user device (think DNS servers etc.
As someone who has beat my head on the IPv6 thing for a bit before giving up (I tried to go all IPv6), what is the "proper" way to setup a home IPv6 network with SLAAC and not DHCPv6?
If DHCPv6 for some reason is essentially always required, why not let subsume SLAAC for IP address assignments?
RFC 8106 IPv6 Router Advertisement Options for DNS Configuration
However, it only handles your address. Apparently there's an extension to make it also provide DNS addresses and so on. If you don't have that, then I guess you configure DNS manually. Or use 8.8.8.8.
It's not like your router is doing some magic DNS auto-discovery, by the way. It just tells devices the addresses that someone typed into its own configuration page.
I'm really tired of hearing it will "Just work" - that's proven to be a lie over and over. But I would love to be shown where these major players do their static blocks for ipv6 (having fought this fight for a while).
Are you using comcast? I think they only DYNAMICALLY assign you a 64 - so you can only create ONE subnet on your entire network. Again illustrating the shortage and difficulty in using IPv6. I'd thought /48 would be minimum PD, but that is not the case. Or even a /60? No go. There are workarounds I'm aware of, but this stuff absolutely DOES NOT "just work".
[1] - https://support.google.com/fiber/answer/6136162?hl=en&ref_to...
> Are you using comcast? I think they only DYNAMICALLY assign you a 64...
In my experience here in San Francisco with both IPv4 and IPv6 service (and IPv4 service elsewhere in the US years and years ago) Comcast will give you a v4 IP (or v6 subnet) for as long as the same edge device (or an edge device with the same MAC address (or DUID for v6)) continues to renew the lease. So, yeah, it's dynamic in theory, but static in practice.
> Or even a /60 [via DHCPv6-PD]?
Weird. Configuring my DHCPv6 server to do Prefix Delegation and request a /60 always worked just fine for me. I was disappointed that I couldn't get a /56 or /48, but was okay with the /60 that they gave me. Again, this was in San Francisco, so maybe other parts of the country are managed _way_ differently. Maybe.
Alternatively, are you _sure_ that the DHCP-PD request was refused and that that you didn't -say- fail to configure your system to actually assign slices of the /60 to your LAN?
...
Actually, now that I'm thinking about it, I seem to recall a problem like you're describing.
If I'm not misremembering that I had this sort of problem, then, maybe, try configuring your edge device to ask for a /60, change the DUID that it will use to make the request, and then bounce the WAN interface (or reboot the device, or do whatever is required to apply the changes). My memory is absolute shit (and likes to hallucinate things that never happened), so this might not do anything useful. But it's usually a pretty easy thing to try.
By "insane churn" do you mean "devices generate and allocate new IP addresses for themselves periodically (maybe daily, maybe more frequently)"? If you do, then that's not SLAAC, that's the head-assed thing sometimes known as "IPv6 Privacy Addresses". From what I've seen on Windows, OSX, and Linux, this makes it so that there's one IP that remains constant, and a parade of addresses that get assigned as time marches on. You can disable it on Windows, OSX, and Linux, and I would recommend doing so.
> SLAAC (vs DHCPv6) seems to struggle in fully configuring an end user device (think DNS servers etc.
Yeah, if you're interested in only using SLAAC, then the best you can do is set the `RDNSS` option [0] in your Router Advertisements and pray that the network configurator in the OS you're using has bothered to pay attention to it.
[0] <https://www.rfc-editor.org/rfc/rfc8106#section-5.1> (Do note that despite the date on this RFC, this option was first specified in 2007, and first specified in a non-experimental RFC in 2010... so, it's not like it's new.)
I think privacy extensions are unavoidable - they default on in many places. So I'm leaving them. Some devices actually rotate more often (ie, when connecting to different wifi points even if underlying network is the same, apple seems to generate another new IP). But compared to ipv4 (where you can almost immediately trace from an IP you have in a log to device) -> you need more support in your tooling to do that with IPv6 and privacy extensions.
Honestly, given that the vast majority of the sites that use v6 "privacy addresses" are going to be end-users at their home, and that most of those folks are going to be either using web browsers, and/or already logged into the servers that are servicing their requests, there are so very, _very_ many powerful ways that folks can be tracked that have absolutely nothing to do with their IP address.
"Privacy addresses" are just a nuisance.
> Some devices actually rotate more often (ie, when connecting to different wifi points even if underlying network is the same, apple seems to generate another new IP).
I'm not sure _exactly_ the setup you're talking about. If "connecting to different wifi points" means "disconnecting from one SSID and connecting to another SSID but still being on the same physical network", then I think that this is OSX randomizing your MAC address and/or OSX generating a new DUID when connecting to a different SSID.
Prefix delegation to customers is necessary if you want to avoid NAT. IPv4 stayed with delegating just one IP address to customer (household) because everyone used NAT in home routers due to IP address conservation.
SLAAC was introduced because people wanted a simpler alternative to more complex DHCP. That is why it is mandatory, while DHCP is optional.
> but at this point I think everyone has admitted that v6 is simply too difficult for most IT departments to implement.
I do not think that IPv6 is too difficult to implement, i rarely heard this argument. The main reason that there is no transition is that there is no economic nor political incentive to do so for individual organizations, so there is a coordination problem.
I am absolutely no expert, but could get my head around ipv4, but IPv6 - I always end up running into a fuss. I really wish they'd expanded address space to 64 bits, a few other tweaks, and called it good. Maybe call it IPv5? Is there any chance of doing something like this.
So many things that are so trivial or well known in IPv4 are a total nightmare pain with IPv6. Some quick examples:
Internet service providers will happily give you a block of static IPv4 addresses for a price. ATT goes up to a 64 ip address block easily, even on residential. Almost impossible to get a static block of IPv6 in the US.
Let's say you are SMB, you want WAN failover. With IPv4 this is simple. You can either get two blocks of static for your upstream, and route them directly as appropriate to your servers, or go behind a NAT and do a failover option. Whent the failover happens, your internal network is relatively unaffected.
Now try to do this with IPv6? You can't get your static IP's to do direct routing with, and NPT and anything else is a mess, and the latency in having your entire network renumber when the WAN side flaps is stupid and annoying.
In many SMB contexts folks are very used to DHCP, they use it to trigger boot scripts TFTP, zero touch phone provisioning and lots more, pass out time servers and other info and more. The set of end user devices (printers, phones, security cameras, intercoms, industrial iOT) that can be configured and supported with IPv6 is so poor and the complexity is so high.
Not all ISP's offer prefix delegation to end user sites. Because you have an insane minimum subnet size with ipv6 a lot of things that for example you just need two IPs (think separate network for customer premise equipment) now need a 18,446,744,073,709,551,616 addresses.
The GSE debacle means instead of a very large 64 bit address space we got an insane 128 bit address space. Seriously, how about 96 or anything else a bit more reasonable.
Even things like ICMPv6 - if you just let it through the firewall you could be asking for trouble, but blocking it also causes IPv6 problems. Ugh. Oh, it's simpler than IPv4 they say.
This causes issues on IPv4 as well, the only difference is that a lot of the dirty hacks and workarounds were removed for IPv6 so that people are forced to deploy it properly.
"forced to deploy it properly" = giant headache. I'm tired of IPv6 folks saying it's a pain in the neck because it's "proper".
With ICMPv4 if you really needed / wanted, you could basically drop ICMPv4 at the firwall edge (with TCP MSS clamping etc). And the attack space with ICMPv4 coming through I don't think was TOO bad.
When folks say they don't need to filter ICMPv6 for things like RS / RA / NS / NA traffic that seems SO SO sketchy to me.
NAT is that IPv6.
It's useful that they use client side certificates. (They call this "authenticated origin pull", but it seems to be client side certs.
https://medium.com/@ss23/leveraging-cloudflares-authenticate...
Authenticated origin pulls should not be “useful”. They should be on and configured securely by default, and any insecure setting should get a loud warning.
Indeed, we do happy-eyeballs where we can and _strongly_ prefer IPv6 when origin host resolves AAAA. However, we still need IPv4, since there is still a big chunk of traffic that only works IPv4.
If the client gives us a chance, we'll strongly prefer IPv6.