11–20 of 399 posts
Perhaps I just misunderstand IPv6 but I prefer IPv4 with NAT and temporarily leased public router address for privacy and security reasons. AFAIK IPv6 means every device gets assigned a stable unique address everybody can identify and reach it by. And I have never seen a SOHO WiFi router that would support IPv6 anyway (perhaps latest fancy expensive ones do).
Perhaps I just misunderstand IPv6 but I prefer IPv4 with NAT and temporarily leased public router address for privacy and security reasons. AFAIK IPv6 means every device gets assigned a stable unique address everybody can identify and reach it by. And I have never seen a SOHO WiFi router that would support IPv6 anyway (perhaps latest fancy expensive ones do).
Also, IPv6 has a unique address that everybody can reach but most if not all routers have an IPv6 firewall that gives at least if not more security than NAT provides.
Perhaps I just misunderstand IPv6 but I prefer IPv4 with NAT and temporarily leased public router address for privacy and security reasons. AFAIK IPv6 means every device gets assigned a stable unique address everybody can identify and reach it by. And I have never seen a SOHO WiFi router that would support IPv6 anyway (perhaps latest fancy expensive ones do).
- IPv6-to-IPv6 NAT has only been accepted very recently and very begrudgingly. Whatever your views are on NAT, the fact is that lots of people have network designs that rely on it, and if you want them to stop, you're now asking them to couple two major transitions, which is a significant economic cost. (Option 3 in this article is IPv6-to-IPv4 NAT, assuming that the public internet will indefinitely be IPv4; it's noteworthy that none of their options ever envision the public internet becoming IPv6.)
- IPv6 recommends the use of its own scheme, SLAAC, for address assignment, with DHCPv6 being also very recent and poorly implemented - for instance, Android has no DHCPv6 support and plans to never implement it https://code.google.com/p/android/issues/detail?id=32621 . There's also a "stateless DHCPv6" for communicating DNS servers but using SLAAC for addressing; without it, SLAAC expects you to use a scheme called RDNSS to communicate your DNS servers, which is also not 100% supported. So you now need to spend engineering time supporting all of these options because some devices only support one and some only support the other, and you need to come up with network designs that work with both SLAAC (which has strong opinions on how you use /64s) and DHCPv6 (which doesn't).
- IPv6 doesn't use ARP, on the grounds that it's a layering violation, a separate layer-3 protocol that runs directly on top of Ethernet but talks about IP addresses. Instead, IPv6 has a clever scheme for using multicast to transfer the information that ARP would convey, by having machines join multicast groups based on their MAC address. This works very, very poorly with networks that aren't designed to support significant multicast load - for instance an attempted deployment of IPv6 caused packet storms in the MIT Computer Science and AI Lab's network for about a week because their switches were falling back from multicast to broadcast: https://blog.bimajority.org/2014/09/05/the-network-nightmare... So a working IPv6 deployment involves upgrading all of your hardware to hardware that has good support for multicast, which is also a significant economic cost.
- Various protocols like Teredo and ISATAP attempt to set up tunneled IPv6 routing in preference to IPv4 routing, making it hard to do a staged deployment, especially if you have BYOD on your network. For bonus points, because they're tunneled, you get different and possibly worse routes over IPv6, making debugging harder. So that's a cost in additional L1 and L2 support.
If someone had come up with an IPv7 that's just "We extended IPv4 to 128-bit addresses and we left ARP and DHCP and NAT and everything alone," people would have switched to it already. But the powers that be are drowning in the second-system effect and nobody wants all the features they added.
Coming up with a solution that looks like a huge technological advancement, with no real respect for the motivations or incentives of those who'll need to implement and use it, is a fairly common occurrence in tech and something engineers should be trained to guard against.
I always disable IPv6 at home and computers I administer. IPv6: for machines (IoT) IPv4: for humans
if it doesnt do ipv6 it's broken
A car is not broken because it does not drive on rail, you can get you to the same places.
There is currently very little you cannot do without IPv6.
What if we started charging a small but slowly increasing annual fee for each IPv4 address? And with the proceeds ICANN starts buying back IPv4 blocks and permanently retiring them.
So this means two things. The first is that the desire to move to IPv6 on the part of the article's authors has nothing to do with public IPv4 address space exhaustion, it's based on other alleged inherent benefits of IPv6. The second is that IPv4 NAT already solves the exhaustion problem - you're either doing NAT to IPv4 or NAT to IPv6 (using your favorite 6preposition4 encoding/tunneling scheme), but as far as the public internet is concerned, it looks like you're doing plain old IPv4 NAT.
I always disable IPv6 at home and computers I administer. IPv6: for machines (IoT) IPv4: for humans
All new contracts are ipv6 and the only way to get to ipv4 is via customer support. However right now ipv4 gives you the better experience.