> Disabling IPv6 because of some -maybe imagined- problem
I've had very real IPv6 problems at home, which has caused me to disable it for long stretches. I turn it back on every now and then to see if life has improved though.
Most of my issues have been down to my ISP only handing out a dynamic /64 prefix. Apparently that's not how you do it and the software side doesn't seem to want to accommodate that, but that's what I got so...
> Most of my issues have been down to my ISP only handing out a dynamic /64 prefix.
Yes, this is my biggest issue with the move to dynamic prefix delegation as well. Delegated prefix change seems to be handled very badly in the stack. It basically breaks all your IPv6 connectivity until LAN hosts get to renew their DHCPv6 leases and/or SLAAC autoconfiguration. Even connectivity between hosts on the LAN will break, since their addresses will slowly change while they update.
The funny part is that I now have a static IPv4 and a dynamic IPv6 - a situation I would never imagine could happen.
Agreed. ISPs only handing out /64 is very aggravating, because one can not subdivide them without breaking SLAAC. One can hand out smaller subnets with DHCPv6, but that is broken in a lot of clients that assume /64 subnets blindly somewhere.
For me it basically breaks all connectivity, because pfSense tells LAN clients to use the public IPv6 address for DNS. So when the prefix changes pfSense updates its public IP, but LAN clients still try to use the old address for DNS resolution.
I've tried to get pfSense to only use IPv4 for DNS address, but I've so far been unsuccessful.
There's also the issue of updating firewall rules.
I'd recommend using ULA addresses for things like local dns servers.
When I was with my old ISP, we'd have our prefix dynamically delegated so I gave important servers ULA addresses. I then used some iptables scripts to allow traffic to my IPv6 services by looking only at the host part of the address, so if the prefix changed, the firewall rules would still be valid and allow access. That coupled with dynamic dns made it possible to still have a reasonably good network.
Since my new ISP gives us static everything, it's all so much easier. I really don't get the point of PD for IPv6. Or atleast, do PD but always assign the same prefix.
> I really don't get the point of PD for IPv6. Or atleast, do PD but always assign the same prefix.
IPv6 allocation rules. They wanted to avoid the situation that happened with IPv4, so the address block are licensed for use and renewed on regular basis, so they can change. There's no such thing as fixed or static IPv6 address, it is dynamic, turtles all the way down. Hence DHCP-PD.
> They wanted to avoid the situation that happened with IPv4,
This is directly contrary to what I've heard. Maybe my information is bad, or out of date, but I had thought that IPv6 addresses were meant to be static. I thought one of the selling points was that we couldn't run out of IPv6 addresses, as they were so numerous. If we're going to keep them dynamic, why even force this monstrous 128-bit number on us?
As far as I've understood, they wanted a little of everything.
IPv6 addresses should be more static short to medium term, because you don't have to reassign. Your local pool is basically infinite, so e.g. a client logging off the WiFi doesn't mean you immediately have to recycle the address. The local part (the latter 64 bits) is enough for everything and everyone.
Now, the first 64 bits should be used for routing, which should preferably be more hierarchical than with IPv4. The idea was that a customer/company/small ISP would get a prefix assigned that was below the hierarchy of the upstream ISP (with IPv4, that hierarchy isn't possible because there aren't enough address bits, and lots of lower-tier customers got their own subnets). So a large ISP might be assigned 2345::/16, assign 2345:6789::/32 to a smaller ISP who might assign 2345:6789:abcd::/48 to a customer (who then will do more subnetting with that). That keeps the global and local routing table small, since everyone just needs to look at the address prefix to know where to route to. If the customer now moves to another ISP, he is assigned a new prefix (e.g. 4711:f0f0:666::/48) by the new ISP and needs to renumber, meaning that all the customers addresses keep their suffix but change their prefix. Protocols like SLAAC where designed as stateless to support (among other things) quick and easy renumbering. Just announce the new prefix, wait a TTL and you are done. Clients automatically switch over to the new addresses, in an ideal world this is mostly transparent to the end user.
In the new millenium, especially after Snowden, the argument of privacy got stronger, meaning that randomised local /64 suffixes are now en vogue, as opposed to the earlier MAC-based static suffixes.
Therefore everything is more dynamic and also more static ;)
Yeah I looked at setting up v6 on all my home boxes a few years ago, and the situation sucked. I basically can't get a static IPv6, in spite of the fact that though I technically have a dynamic IPv4 from my ISP, it never changes. So now I'd have to go setup dynamic DNS and a bunch of other stuff to get it working. With the size of IPv6 address space, I figure ISPs should have no problem handing out static IPv6 addresses.
I've had very real IPv6 problems at home, which has caused me to disable it for long stretches. I turn it back on every now and then to see if life has improved though.
Most of my issues have been down to my ISP only handing out a dynamic /64 prefix. Apparently that's not how you do it and the software side doesn't seem to want to accommodate that, but that's what I got so...