DNS infrastructure sprinting to IPv6 while users lag IPv6 might be moving slowly among the general community, but it's penetrating the Internet infrastructure at a much higher rate. In an article published at his Potaroo blog, Internet address Registry for the Asia Pacific region chief scientist Geoff Huston has published the results of a study into how many servers in the …
The buck stops right there, and that's probably the problem in most cases. Servers have been capable for a long time, and most operating systems within the last 10 years have supported it out of the box. That leaves a few very old consumer routers and the ISP - who is really the culprit in the slowness of this transition.
PS: No, I can't change ISP because there isn't another one offering service where I live. That's probably the case in most of North America.
That leaves a few very old consumer routers and the ISP - who is really the culprit in the slowness of this transition.PS: No, I can't change ISP because there isn't another one offering service where I live. That's probably the case in most of North America.
For us, the thing that kills IPv6 is AAPT (our ISP) and the Cisco SG-500X, which will do layer 3 routing on IPv4 but not IPv6.
And I don't do IPv6 because MS does. Last resort to limit Windows phoning home (and I don't mind to use it)
I'm surprised you're doing IPv4 because Microsoft does that too. Or did you code up some hack to let you post HTTP over IPX/SPX?
I have yet to see a convincing reason for why I should even consider changing our current network from IPv4 to IPv6.
The only reason I can see for IPv6 is to feed an IoT botnet as we have seen recently. Not everything on a network needs an IP address that gives it individuality on the web. In fact, most shouldn't be on the web anyway, think industrial CAM machinery and then think of what could happen if the script kiddies started playing with that.
Would those that down vote please give reasons for doing so, that way we all learn.
Here you go - one downvote.
1. IPSEC to all hosts on my home network.
Firewalls are for restricting network access. NAT is a routing bodge. Do not confuse the two.
2. Ending CG NAT, esp for phones.
Consumer routers do need new capabilities. How about a phone app which does OCR to identify sticker or screen-based IoT access rules sensibly, then pass them on to the firewall.
Oi, IETF - how about a standard for describing security rules, preferences and requirements? Things like - "here's my CSR, give me a cert please" so that humans don't have to understand exactly what's going on, but you can have decent security? Currently security admin is too hard.
Thank you for that.
You have started to make a case for its use with consumer products but you missed the industrial case where machinery needs to be on a network for inter machine communications but absolutely DO NOT need to have the possibility of being seen from the web (this is where the panic about infrastructure hacking comes from). Anything that even hints of making that easier is a no-no, firewalls can, and are, breached so they are not the ultimate protection. Why make it easier for industrial hackers?
The case for industrial use of IPv6 is that fe80::/16 is supposed to be wired into the hardware as non-routable and provides as large an IP space as any size SCADA operation should ever need, including the use case of merging with another IPv6-enabled SCADA network sometime in future.
Yea olde RFC 1918 spaces 192.168/16 and 10/8 etc do not give you that level of security or flexibility.
"olde RFC 1918 spaces 192.168/16 and 10/8 etc"
Maybe try unique local addresses (used to be called site-local, but someone wanted to kill NAT). fe80::/16 is a local hardware address that is not really usable for anything but getting a real address. What you really want is RFC 4193 addresses. Once that you can actually use with NAT such as FC00::/7. Plus the unique local address range is much bigger than anything else you can get for IPv6.
Also, done forget RFC 1918 is more than just 192.168.0.0/16 and 10.0.0.0/8. It also includes 172.16.0.0/12.
Another downvote. You're commenting on this kind of article while promoting your own network limitations as an example of practice you'd expect others to follow ? So you can reasonably be expected to know about IPV4 address depletion and the consequences of breakage which we will all suffer from as a consequence of a complex and extended transition through dual stack systems to IPV6 only. This will involve, for example, mobile applications and IoT which can't be cleanly and securely developed because individual IPV4 addresses can't be allocated to consumer devices. As a conseqeunce firewall breakage is increasingly likely due to ugly hacks trying to fix such problems to make communicating software server components for more advanced distributed applications operate within a carrier grade NAT or worse environment.
One such consequence is the centralisation and loss of privacy and security due to IoT boxes only being able to talk for many purposes to each other via centralised servers operated by the manufacturers of such devices.
If you want to be able to comment with more knowledge on a technical article about this subject, you could at least figure out what you need to do to access one of the existing and available zero cost tunnel brokers. For someone who needs to know how to maintain security and services during the likely extended transition to IPV6 only networks, I consider getting some experience running dual stack IPV4+IPV6 capable servers, services and home networks pretty much essential.
How about the benefits we'll get from the future?
IPv6 is better at handling network latency.
It has extensions which allow for yet to be thought of ideas without everybody needing to upgrade.
It has multicast build in, which one day could free up airwaves for more mobile internet usage. (Although by brother is aghast as the thought of TV and radio airwaves being given to mobile and WiFi operators).
I'm not sure that there *is* a compelling case for a single end-user to run IPv6. SLAAC is easier than DHCP, but if you have a decent consumer router then the combined DHCP+DNS in that box ought to be working fine without you needing to understand it.
There certainly is a compelling case for *everyone* to use it, since we are now well over the IPv4 addressing limit and routing tables at the backbone level are stupidly large. The IPv6 address space is large enough that routing can be done purely by prefix and routing tables become pretty trivial. That benefits everybody, but not by much until nearly everybody has switched (which is probably why no-one sees any personal benefit in being an early adopter).
As regards "other features of IPv6", things like IPsec have mostly been back-ported to IPv4 as far as I can see and whilst it is true that you should not rely on NAT for domestic protection, I believe it is also true that no consumer routers actually do. (People may *say* they are relying on it, but their router always *does* have a firewall.)
There are a few kinds of end-user-facing applications that would be easier to configure under IPv6, but whether it is safe for the majority of end-users to deploy such apps on their network is another matter. It seems to me that you only need IPv6 addressing within your home network if you have a device there that you want to expose to world+wife and it also seems to me that most people should be dissuaded from doing that.
On the other hand, if all your shinies actually support IPv6 (and it has been in all mainstream OSes for the last ten years) and your ISP and router support it, then I can see no downside to leaving it enabled. I imagine that eventually IPv4 will be confined to squillions of (domestic) islands populated by ageing and probably vulnerable gadgets, now safely firewalled off from the wider IPv6 internet, which switched off all IPv4 support because no-one could be arsed to maintain the terabyte-sized routing tables required to make it work.
"I'm not sure that there *is* a compelling case for a single end-user to run IPv6."
End users simply shouldn't care; it should all be under the covers. If you have a modern end-user o/s, with a home gateway and ISP that support IPv6 dual-stack, it just works. That was actually a design feature... so it's the ISPs and DNS operators who just have to do the professional thing, deploy v6, and wait a few years before they rip out those disgusting "carrier-grade" NATs. By the way, that very phrase "carrier-grade" stinks of old-fashioned monopolistic telcos. So you just know they're a Bad Thing.
By the time you get to 25th on the list, you're looking at a resolver that handles a mere 0.4 per cent of queries.
Given DNS has been architected to spread the load, it does seem that having so few servers handle so much of the traffic does seem to be a disaster waiting to happen, especially if IoT takes off...
Given DNS has been architected to spread the load
No, it is not to spread the load. DNS is architected to spread the administration so that the DNS for a ${something} can be managed by someone local to/supporting that ${something}.
Thus I can run my own DNS servers for my own domain - all they have to do is serve up record for my domain to outsiders, and server up resolved records to internal devices. The DNS architecture allows me to do that easily by setting the NS records (and glue) at the registry - rather than being beholden to ${some_big_organisation} and whatever they let me do with it.
That latter scenario was the case in the early days of the internet, when you had to get an entry put in a global hosts file, which was then synced out periodically to the few hundred/thousand systems then online. As you can well imagine, that didn't scale too well as the internet grew - hence why the heirarchical DNS as we know it today was developed.
Spreading the load is done by the same techniques that are used for spreading other loads. For example, 8.8.8.8 won't go to just one Google server - it'll be anycasted and load balanced between probably many thousands of servers spread across different parts of the world and internet. That load sharing isn't specific to the architecture of DNS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
