I get v6 on my mobile and on my broadband, and in all respects it seems to work well for making the internet end-to-end addressable again. With the devices like RPis and VMs/containers, the simplicity is refreshing vs hacks involving port forwards or using a for-$$ service as a proxy.
- IPv6 ready hardware. I went through several routers (Asus and similar), and it wasn't until I ended up with pfSense that IPv6 actually worked for more than a couple of hours.
- IPv6 ready software. Some software just gets slower when it first tries IPv6, fails and falls back to IPv4 (especially noticeable browsing the web). Some software gets all confused about IPv6 being present and stops working.
- IPv6 requires DNS, even with static prefix (I have dynamic prefix). For servers, that means per-server dynamic DNS entry. Very few DynDNS providers supports dynamic AAAA records, at least when I checked last year. And getting DynDNS clients working on the servers was a nightmare.
For IPv4 I just need to keep one DNS entry up to date, with plenty of DynDNS options all around.
- Dynamic prefix requires firewall rules to be updated when prefix changes. I wasn't able to figure out how to configure this in pfSense, though I admit I had lost some motivation at this point.
As a residential user who still gets a proper IPv4 address from my ISP, IPv6 doesn't really bring that much to the table. I still have to fiddle with my router/firewall, and at this point IPv4 NAT is a lot simpler to configure (linking rules to NAT entires for example).
This is not an IPv6 issue. Most cheap routers are garbage and cannot even handle newer IPv4 RFCs correctly. The other fault could be at your ISP. I need to ask mine for both a prefix delegation assignment and a non-temporary address assignment.
> IPv6 requires DNS, even with static prefix
False. You can statically assign whatever /64 host number you want to any interface, as many as you want per interface (for example you can bind each service you run to its own IP, to frustrate port scanning). You can use static assignment at the same time as IPv6 autoconfig, the latter is built to avoid collisions. This is a huge improvement on IPv4.
> Very few DynDNS providers supports dynamic AAAA records
So ask them. Or run your own DNS server.
> Dynamic prefix requires firewall rules to be updated when prefix changes.
That is the DHCPv6 client's job. You should be able to provide a script that the DHCPv6 client runs on server reply messages.
I am an IPv6 n00b, literally set up IPv6 on my home connection seven days ago, and have not stopped being excited about it since. No more fiddling with port forwarding garbage or configuring DHCPv4 to hand out reserved addresses for known MACs. IPv6 is an amazing improvement to IPv4 in so many ways. Wish I had taken the time to learn about IPv6 and set it up sooner.
It's not an IPv6 specification issue, correct. It is an IPv6 adoption issue. My ISP has provided IPv6 for 5 years, only last year did I get a router where it worked (apart from the other issues I've mentioned).
>> IPv6 requires DNS, even with static prefix
> False.
Of course it doesn't _technically_ require DNS, but in practice I'm not going to remember the 16 hex digits that is my prefix. And that's before SLAAC.
>> Dynamic prefix requires firewall rules to be updated when prefix changes.
> That is the DHCPv6 client's job. You should be able to provide a script that the DHCPv6 client runs on server reply messages.
Why should I have to provide a script? At most, I should be able to check a box on my router/firewall. Ideally I shouldn't have to mess with it at all.
For DAB, the rise of mobile data means far fewer listens to radio. Any audio quality increase turned out to be moot (they added more channels instead, besides streaming services has similar or better quality).
For IPv6, we now have a huge amount of actual clients (primarily mobile devices) with relatively few actual servers. In addition, security means companies use VPN or similar. This means the pool of devices who needs to be globally addressable is much smaller than it was. However the mobile devices can hop from network to network, and this isn't something IPv6 addresses any better than IPv4 (they'd still get a new address).
That's just my uninformed POV of course and I'm probably a bit harsh on IPv6 given all the frustrations I've had trying to get it working.
IPv6 is designed to address this use case: https://en.wikipedia.org/wiki/Mobile_IPv6
What's easier - connecting to something your OOB management network (10.10.1.0/24) - the fw is 10.10.1.1, the switch is 10.10.1.11, the 5 servers are 10.10.1.21-26, etc etc...
That's a bit better than typing 2200:Hb43:4432:FE39:019H:F3Z6:3438:2101 etc...
I realize internal dns solves that, but that's a lot of extra dns records to maintain - which ALSO is an issue if your organization uses HSTS and preloads subdomains - you must have have a trusted certificate on each management interface, otherwise the browser simply won't let you manage those things over a GUI - or, of course, being your own CA and loading your intermediate and/or root into every deployed box on your network of every person that could potentially have to manage those devices over HTTPS.
That's literally my only issue with ipv6, in all honesty.
Either because your new colleagues don't have the same memory as you, or because switch 10 and server 1 are now conflicting...
HN discussion: https://news.ycombinator.com/item?id=17060437
For one, address allocation is entirely different. Devices will have several addresses, and some of them can be temporary addresses.
If your ISP assigns you dynamic prefixes (mine does), you can end up with devices not being able to connect to the internet after the router/modem reboots, since they're not told about the new prefix you just got from your ISP and happily keeps using the old one.
If your ISP assigns you dynamic prefixes (mine does), dynamic DNS is required for each server box (apparently one can centralize this by using DHCP-PD, but I haven't figured this out for my pfSense router).
And if you're writing an IPv6-enabled application, parsing client/server address input is a PITA compared to IPv4.
The list goes on and on, but these were the major pain points I found while trying to use IPv6 at home, which are non-existent when using IPv4.
Meanwhile it never hurts to automate your handling of renumbering, it'll happen eventually anyway - just like letsencrypt short expiration times actually help you avoid cert expiration problems.
You have a broken router setup, it's not doing router advertisement. Every reply of yours in this thread is just you complaining about something that you misconfigured on your router or did not bother reading about in any decent IPv6 introduction. Please stop the FUD.
Well there goes your problem…
For whatever reason I get a new IPv6 prefix every time the modem or router reboots.
That's the understatement of the year. IPv6 is a huge protocol and its complexity is its main weakness and one of the main reasons people and organizations stay away from it.
You are completely ignoring routing issues. IPv6 is designed from the ground up for efficient route aggregation, and more importantly the processes ARIN and RIR use for allocation are based around this. There is no way IPv4 routing would scale to what IPv6 is going to be in 10 years if you "just added" some octets. What are you going to do, force everyone to re-number?
Theoretically yes, in practice not at all. Just one major difference: No NAT any more.
The funny thing is, there will be mandatory NAT on the carrier side during transition to IPv6 because of unwillingness of major websites to announce AAAA (including this one). See [0] for some transition method examples. The common theme of these methods is: They spoof DNS to point to fake IPv6 addresses, which is horrible, HORRIBLE, but hopefully motivates IPv4 holdouts to move to IPv6, announce AAAAs.
If you want to see what a wasteland IPv6 still currently is, and why such transition NAT madness will be necessary (sadly): Try disabling IPv4 when you have native IPv6 and your carrier has not enabled such DNS spoofing transition methods yet.
For most users, the transition will happen via dual-stack (where the customer runs their own IPv4 NAT), not NAT64.
If so, that is a difference from IPv4. Don't block IPs, block subnets. Block the whole /64. It's what you were doing with IPv4 anyway - blocking a whole building / office / etc at once!
That's still no reason to turn IPv6 off in my humble opinion...
Most stuff defaults to bucketing by /64s.
IP blocking is far from ideal, in both versions of IP.. IPv6 makes this no better, or worse.
It's entirely reasonable to say "It works fine without [=zero business value], no need to invest that amount of work.". This makes IPv6 a negative value proposition for many orgs.
I mostly focus on users of VPN services. It's still rare for them to handle IPv6 traffic. So if you have IPv6 connectivity, IPv6 will leak, bypassing the VPN. Unless you have firewall rules, or disable IPv6 while using the VPN.
I'm in India and my mobile service provider (Jio) is handing out ipv6 addresses. The fascinating thing about this is I was able to access a server hosted on my phone from Internet. Crazy!
I am loving this era.
Maybe a firewall would be prudent ;)
Millions of people unknowningly use IPv6 every day: smartphone users on mobile networks. You either get an IPv4 address in 100.64.0.0/10 Carrier Grade NAT space or RFC1918 10.0.0.0/8 space, and a fully routeable IPv6 address. Your mobile application experience tends to be far better with services that can take advantage of native IPv6 connectivity.
IPv6 almost seems to be the networking equivalent of DAB radio at this point. A once futuristic tech that grew old in the tooth waiting for its moment.
At least IPv6 is getting developed and it's is easier to update than DAB, so one can hope that one day in the far future it becomes usable to people like me.