18 ms·

IPv6 Is a Nightmare

146 points by whereistimbo 6y ago

usr1106 6y ago
Not very convincing. Addresses cannot be handled by humans? The same is true for all modern computing. Intels CPU has several prefetch queues, some with more than 200 entries. Who can handle this? Well, not even Intel's engineers as Meltdown and the later discoveries have shown. Have you looked how a GPU works? Recently there has been discussion that Kubernetes depends on 200 libraries. The list goes on and on. That said, he might or might not have some point in the address translation section. But not being an expert in IPv6, he has wasted his trust by useless complaining before he gets to the possible beef.
- Arnt 6y ago
  AIUI, address translation isn't how it's done. Rather, if you want the hosts on a network to be reachable under some other prefix, you advertise that other prefix (in addition) and then the hosts have an extra address. IPv6 hosts have lots of addresses. v4 needs to scrimp, v6 doesn't.
  - jachee 6y ago
    The analogy that really drove home how many IPv6 addresses there are is this: Take every known star in the sky today, give each of them a full IPv4-sized /32 address space, and you'd still have IPv6 space left over. No need to scrimp, indeed!
    - bb88 6y ago
      Not sure why you're being downvoted here, since the point is valid. I calculated the number of IPv6 addresses per square meter of the earth's surface and got a similarly large number.
      - usr1106 6y ago
        So what would have been an ideal length for you? I think the fixed separation into centrally and privately managed halves is a good idea. 48 + 48? Would that stop your critique? I guess that would cause all kind of alignment issues. 64 + 32? Probably enough, but the gain seems marginal to me.
        bb88 6y ago
        To be honest, other than running out of space, the length of an IP address has never truly mattered, because you don't typically use the IP address to access microsoft.com, e.g. Also routing uses subtrees, so we could have had just grown IPv4 with an extra 4 octets too. Does every cold virus need an IP address, no. But on the other hand it might make sense to give every planet and asteroid in the solar system one.
      - Arnt 6y ago
        He may be downvoted because counting that is a bit disingenious. The central concept in v4 is an interface, which has a 32-bit address and of which a host tends to have one. The central concept in v6 is a network, which has a 64-bit address and which may be populated by one or many hosts. The number of /64 network addresses per m² of the planet is also a large number, I'm sure. (That it is a large number is intentional, in order to permit simple routing even when that simplicity leads to lower addressing density.) But counting that is honest in a way which counting /128 addresses isn't.
- himinlomax 6y ago
  > Not very convincing. Addresses cannot be handled by humans? Yeah it's the weakest critique against IPv6. There's plenty to complain about, this is just pointless.
- theon144 6y ago
  >The same is true for all modern computing. Yes it is. Is this a beneficial trend? If not, is it not worthy of critique?
  - usr1106 6y ago
    Not necessarily. I am also sceptical of the extreme optimization tricks done for Intel architecture CPUsm because they lead to security vulnerabilities. A simpler RISC style ISA would be preferable. And of 4K displays, because the complications it brings for (Linux) desktops and more importantly the increased power consumption it causes for irrelvant benefit for the majority of users. I could continue the list, I still enjoy to run Linux on a laptop with 2G of memory (not for building Yocto, but for basic web browsing and doing script programming at least.) Incidently it has no problems with IPv6. But losing that many words about addresses not to be used by humans anyway seems out of proportion for relevant critique.
Lammy 6y ago
> Well, by breaking it again, naturally. To connect to a raw IPv6 address, you wrap it in square brackets. To connect to 2607:f0d0:1002:51::4 directly, that’s http://[2607:f0d0:1002:51::4]/ http://[2607:f0d0:1002:51::4]/ Why is this a thing?!. It's even sillier in Windows Explorer where UNC IPv6 paths are the IPv6 address "with the ':' characters replaced by '-' characters followed by the '.ipv6-literal.net' string": https://docs.microsoft.com/en-us/windows/win32/api/winnetwk/nf-winnetwk-wnetaddconnection2a#remarks https://docs.microsoft.com/en-us/windows/win32/api/winnetwk/... For example, I mount my NAS as "\\fd13-c001-7232-1-13--36.ipv6-literal.net"! https://i.imgur.com/waLJRFf.png https://i.imgur.com/waLJRFf.png
- lolc 6y ago
  I bet your NAS has a mDNS name. If it doesn't, configure it!
  - Lammy 6y ago
    It’s a point-to-point 25Gbit fiber link directly between the two machines, not switched like the rest of my network, and I didn’t feel like complicating it more than that :)
PikachuEXE 6y ago
I noticed this article talks about IPv6 version NAT - NPT ``` Remember, this will blindly just swap prefixes in and out. Gone are the days of “only the traffic I explicitly create a rule for can get in”. See, now, just adding that one step will, be default, expose your entire network! You now need firewall rules to block what you don’t want and add explicit allows, this time manually as an additional step. This is more of a “default pass” routing — unless I tell you not to, let it through. ``` This seems like a great security concern Would be good to know if this statement is accurate I might consider disabling IPv6 if this is true
- redis_mlc 6y ago
  If you're concerned about security, yeah I would disable IPv6. Until all firewall and router mfgs. re-QA every little feature added for IPv6, you don't really know what your equipment is doing.
  - redis_mlc 6y ago
    Can somebody explain what the downvotes are for? Are you IPv6 fanbois? Have you audited all the firmware and software on your firewalls and routers?
    - alphager 6y ago
      Have you audited the IPv4-codepaths? Your comment contained no information above "I don't trust it".
      - redis_mlc 6y ago
        > Have you audited the IPv4-codepaths? Are you for real? There's been decades of production experience with IPv4 and does mostly what's expected. Of course IPv6 shouldn't be trusted. New software has bugs. That applies doubly for networking code. Get your fuzzers started ...
  - josho 6y ago
    To provide a data point to your assertion my brand new tp-link wifi router has a setting for ipv6 firewall, but it does nothing. Yes all my home devices are exposed to the public internet. Yikes! The tech support team even confirmed that ipv6 firewall support is coming ‘soon’. Meanwhile my ASUS router’s ipv6 support is broken as well for dns configuration. So, yeh it is still early days for consumer ipv6 adoption.
diegocg 6y ago
>Even though the entire “special” address assignments are exactly 1.271% of the entire IPv6 address space, we’re still allocating giant swathes of addresses. History repeats itself, you can see that right here. So what? The whole point of IPv6 is that wasting address space like that is irrelevant - there is going to be enough space regardless
- mikeyjk 6y ago
  I listened to a podcast where Geoff Huston argued that the address space of IPv6 when compared to IPv4 isn't going to give us as much runway as people suspect: https://pca.st/episode/a1df7379-853f-4b5b-af5d-fcb6ad7e1390 https://pca.st/episode/a1df7379-853f-4b5b-af5d-fcb6ad7e1390 Can anyone let me know if he is wrong? It really challenged my perception that IPv6 seriously future proofed the need for a larger address space. "By the time we run out of v4 with NATs, v6 will offer us no more bits"
  - kstrauser 6y ago
    Can you give a summary? ISPs would have to assign a /32 prefix to every connection before we'd be in the same boat as IPv4, but my ISP gives out /64 prefixes (and so uses a 4-billionth as much of the address space as IPv4 does).
    - magicalhippo 6y ago
      Didn't have time to listen to the whole thing yet, but from what I gathered it's two things: the lower 64bits of the 128bit addresses doesn't count (due to privacy), and that carrier-grade NAT might go much further than what some people think. If all you want to do is to watch YouTube and check out Instagram, and Google and Facebook have servers in a rack "nearby" (in the network sense) ala what Netflix does, then you don't need a globally unique IP to talk to them.
      - Dagger2 6y ago
        If we're going to talk about "need", then you don't even need a computer. You could walk over to the rack and watch the yougram on its management console. But there are advantages to having a computer. Similarly, there are advantages to doing your networking right, and that means globally-unique IPs.
ktpsns 6y ago
One problem I rarely read about IPv6 is the mixing of responsibility levels. Sure, we have 2128 IPv6 addresses or so because nobody knows how internet infrastructure will look like in 30 years (maybe internet node virtualization is gone mad). But it's my feeling that the IP address should only be an address and not that half-mixed anonymity-related thing. See, a general problem I see with IPv6 and all the protocols around is their enormous complexity. As a hobbyist in the last decades, you could learn about IPv4 and DHCP in a couple of afternoons. It was simple the same way as HTTP1 was simple compared with HTTP2. Complexity means the learning curve is enormous and in the end only a fraction of experts will understand. My personal opinion is that complexity in computing will evventually kill everything: security dies first, innovation comes last. Sorry for this rant. I assume the IPv6 design was carefully crafted by gifted and highly skilled people. We'll use it anyway, some day :-)
- lxgr 6y ago
  > As a hobbyist in the last decades, you could learn about IPv4 and DHCP in a couple of afternoons. The same is true for IPv6! Granted, beginner-friendly documentation is a bit harder to find, but I was able to set it up for my home network through OpenWRT in a couple of afternoons as well. In the process, by necessity I also learned something about setting up local DNS properly, which in the end has been very beneficial also for IPv4 hobbyist use cases. The comparison with HTTP1 vs. HTTP2 seems a bit unfair – it was never possible to write plain IPv4 packets to the network via Telnet/nc. And if you're talking about the availability of tooling: Don't forget that IPv4 is several decades more mature than IPv6 :)
  - ktpsns 6y ago
    All your points are valid. I have to be honest, I was always scared off the sheer amount of protocols and ressources around IPv6. It felt that I have to deal with anycast, self-organized networks, anonymous embedding of MAC addresses, some NAT-replacement, etc. when I touch IPv6. It's probably not true and one can start with IPv6 also in a simpler fashion. Maybe I'm also just too much used to ifconfig and nat tables that the switch feels hard. The comparison of HTTP1 vs. HTTP2 is in fact only valid on a level of complexity. As an hobbyist, I'm actually quite excited of finally abandoning NAT and being able to reach my Raspberry at home from anywhere in the net. This dream is still far away, given that many places don't have access to IPv6 (without a tunnel).
viraptor 6y ago
> With NPt, you cannot do this, you’d have to have an additional device like a layer 7 proxy (like HAProxy) to take in everything and send it to the correct destination This is mostly incorrect. Yes, NPT can't do this. No, you don't need an additional proxy. All the usual methods work, they're just not called NPT. On linux MASQ and REDIRECT targets work on ipv6. You can change addresses and ports exactly the same way you'd do it for ipv4. There are other wrong things in this rant too. I'm curious if the author ran into many issues while implementing ipv6 or just doesn't like the idea in general. The problems and some solutions seem very contrived and there are better ways to solve them.
lxgr 6y ago
Much of this boils down to "IPv6 sucks because it's so different from IPv4", which has never been a very convincing criticism to me. The conclusion of "It's hard to memorize or type plain IPv6 addresses" has always been "I guess I need (m)DNS" for me, not "wow, IPv6 is bad". And some years later, I'm extremely happy I don't have to memorize even local IPv4 addresses anymore – mDNS together with a proxying/caching local router works that well. Regarding the "unnecessary" changes (i.e. everything besides just adding 96 more bits to every address): When implementing a new IP protocol version literally touches every single device on the network (at some point), why not use that opportunity to revisit some of the historically grown cruft?
- magicalhippo 6y ago
  For me IPv6 sucks because it doesn't really solve my problems in a better way, and instead seemingly introduces a lot more fragility and complexity. I still have to mess with the firewall to open ports, not much different from doing IPv4 NAT as my router software (pfSense) automatically creates firewall rules tracking the port mapping. Except it is worse, because my firewall software don't track IPv6 changes so breaks whenever the device gets a new IP (say new prefix). When exposing services to the internet it's even more PITA since each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP. IPv6 on the LAN is quite a pita due to the massive "random" prefix, gone are the days of easy addresses like 10.0.0.12. Yeah I guess I could just use the local address space but what does that really bring over the IPv4 that I know? And then there's the software that just doesn't follow the times. My router just doesn't handle getting a new prefix. Yeah OK the initial IPv6 wet dream was for an eternal prefix. But clearly that's been unrealistic for quite some time, and sadly not all software has caught up. I will admit that some of it is probably down to me learning more. But I struggle to find the motivation. There's no "killer app", just a lot of pain so far.
  - morsch 6y ago
    When exposing services to the internet it's even more PITA since each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP. Presumably because you configured the forwarding on the router? I mean, that should still be possible, right? Set up a name for the routers IP, and have it forward the connections statically. IPv6 on the LAN is quite a pita due to the massive "random" prefix, gone are the days of easy addresses like 10.0.0.12. Or just use the hostname? Sometime a couple of years ago, local names just started working, sort of on their own. My Synology is nas.local, Linux boxes are reachable using their configured hostname, even my elderly printer shows up as vigor2.local.
danbmil99 6y ago
-4 ftw
eddyg 6y ago
One actual problem not mentioned in the article is that, by default, SLAAC embeds the MAC address of the interface when generating the autoconfigured IPv6 address. As an example, if an interface’s MAC address was `01:23:45:67:89:ab`, the lower 64 bits of the SLAAC assignment (the “host” part) results in an IPv6 address of `:123:45ff:fe67:89ab` (the extra `ff:fe` bytes are constant, making it more obvious the surrounding bytes are likely a MAC address). This has huge implications to privacy, since even as you roam and change networks (and thus the upper part of the address changes), the lower 64-bits stay exactly the same, making it easy to “follow” a device from session to session and site to site. This was addressed by an update to SLAAC: “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” in RFC 4941[0]... but it has to be explicitly enabled on a per-interface basis. A great thing about this feature is that these random, private addresses timeout and become “deprecated” (and a new random address gets assigned to the interface and used for new connections), making it harder for third-parties to track connections over the long-term. Unfortunately, address privacy is a SLAAC thing, so if you want the benefit of registering a device on your network (via DHCPv6, so you can actually correlate IPv6 traffic on your network to a device), you don’t get the benefits of SLAAC’s privacy extensions. [0] https://tools.ietf.org/html/rfc4941 https://tools.ietf.org/html/rfc4941
- admax88q 6y ago
  > This was addressed by an update to SLAAC: “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” in RFC 4941[0]... but it has to be explicitly enabled on a per-interface basis. That's not really a problem with ipv6 so much as a problem with defaults. Nothing stops distributions from enabling the privacy extensions by default, and I'm sure many already do.
- Dagger2 6y ago
  I would argue this is barely the default these days. Windows, OS X, and on the Linux side network-manager, dhcpcd, systemd-networkd etc all have privacy addresses enabled by default. Many OSs/distros also have RFC7217-style addresses enabled by default too, so even the SLAAC base address doesn't contain the MAC on those. DHCPv6 does actually implement temporary addresses too. Support for that is legitimately rare though.
audunw 6y ago
As a networking novice that article actually made me feel positive about IPv6 during most of it. I feel like maybe firewall based security is a bit of an outdated model. It’s going to take a while to figure out how to secure our networks/devices well, but it feels like a model that pushes more of the configuration to the device will be more secure and more universal (since more and more devices will be LTE connected) The model where you by default have access to everything inside the network if you can just get a connection behind the firewall never seemed all that great to me. If we can’t assume that any connection from the local network is authorized anymore, maybe it’ll push us to make servers/services more inherently secure, and accept/reject connections based on actually authenticating the user/device connecting to it. But then again, I’m not a professional so I may be wrong.
- benc666 6y ago
  A layered approach to security (onion model) is the only sane approach because any given layer will always have flaws. The notion I get from the article is that security becomes a huge problem when every node is exposed to almost every other node by design intent. That's why NAT is mentioned several times.
  - djhaskin987 6y ago
    Exactly. Security at the endpoint level, rather than the firewall level, means that those that build those applications are in charge of security. There is no way my multi-business-unit company is going to solely trust developers with its security and compliance story. It's going to hire people whose job it is to secure the network as well. Given that these people don't even know all of the developers (or yet even their managers) inside this multi-business business, the only good thing those people have is firewalls and traffic inspection at large.
    - bb88 6y ago
      You're still going to have a firewall, it just won't be NAT based.
Cyder 6y ago
Hasnt the privacy issue been helped by using temporary ipv6 addresses? This is why my Windows machines have 3 v6 address with only one being permanent and the other 2 being called temporary? The temporary address did change after a restart. I checked my Linux VMs and none of them have this security feature yet.
- moviuro 6y ago
  > I checked my Linux VMs and none of them have this security feature yet. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/ip-sysctl.rst?id=b38e7819cae946e2edf869e604af1e65a5d241c5#n2053 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  - kstrauser 6y ago
    Yep, and while I'm too lazy to dig into detailed kernel histories, that's been in there for at least 9 years now: https://home.regit.org/2011/04/ipv6-privacy/ https://home.regit.org/2011/04/ipv6-privacy/ Short version: echo "2">/proc/sys/net/ipv6/conf/eth0/use_tempaddr turns on privacy extensions on eth0, and makes them the preferred addresses.
    - MayeulC 6y ago
      Also, I think this is enabled by default in NetworkManager, which takes over that kernel option when in use. On servers, not using a temporary address is a sane default.
      - kstrauser 6y ago
        Yeah, that seems appropriate.
commandlinefan 6y ago
> Some devices might have a high-MTU link on one end, and a lower MTU link on the other. Good lord, is this really still the case 1/5 of the way through the 21st century?
- kitteh 6y ago
  Yes. Which raises the question why don't we have something to detect/mitigate this.
  - cesarb 6y ago
    In my opinion (with hindsight), the IPv4/IPv6 model of "drop packets which exceed MTU" as the alternative to fragmenting packets was a bad choice. It would have been much better to take a third option and truncate the oversized packet. That would avoid both the bad effects of fragmentation (slow path in the routers, memory use in the receivers, non-initial fragments which lack the higher level headers making it a pain for firewalls) and the bad effects of dropping (waste of the bandwidth to send the dropped packet, broken firewalls discarding the ICMP message, CPU use in the router to send the ICMP message).
    - Olipro 6y ago
      Except in practice this is useless because you're now transmitting what is basically a corrupted packet. For this to work, L4 protocols would need to be completely redone to consider and work with this concept. Also, what is actually meant to happen is that an ICMP(v6) packet too big message is supposed to be sent back to inform the sender that they need to reduce the packet size. Unfortunately, with the pervasiveness of idiotic firewall configurations that blanket block ICMP, this falls apart which is why we have to deal with ugly hacks like TCP MSS mangling.
  - toast0 6y ago
    There's path MTU blackhole detection. See RFC 4821. This or similar systems are enabled in most mainstream operating systems (but not Android, because Google would rather replace TCP with TCP over UDP than fix TCP with existing fixes). Like cesarb's sibling comment, I think router driven packet truncation would be useful. IP fragmentation is generally problematic and router driven fragmentation was eliminated from IPv6, but truncation with in-band indication would work a lot better. For TCP, the kernel on the receiver of a truncated packet could send an in-band ack of the received bytes, with a tcp option indicating the effective MTU. For UDP, it would be a bit more complicated, you would need to alter the recvmsg syscall to provide both the original size and the received size, and transmitting that information back to the sender would be protocol specific of course. The sender would then either trigger IP fragmentation to appropriate sizes or some protocol specific fragmentation.
tashian 6y ago
The "zone index" they mentioned can make for even more unwieldy URLs than described here. A browser doesn't have to accept: http://[fe80::1ff:fe23:4567:890a%eth0]/ http://[fe80::1ff:fe23:4567:890a%eth0]/ Because of the ambiguity around '%', the browser may require: http://[fe80::1ff:fe23:4567:890a%25eth0]/ http://[fe80::1ff:fe23:4567:890a%25eth0]/ I'm not sure how common this would actually be—neither of these URL forms are valid in Firefox or Chrome on my machine today. Source: https://tools.ietf.org/html/rfc6874#section-3 https://tools.ietf.org/html/rfc6874#section-3
- WorldMaker 6y ago
  As the article points out the zone identifiers are primarily for making sure you are sending packets out on the right device (network adapter) and extremely rarely play into receiving data, so it would be extremely uncommon/unlikely to see zone identifiers in URLs because presumably they would only make sense, pending some unspecified future usage, for diagnostics on a single device (as the zone identifiers mostly don't "leave" a specific device; they aren't advertised externally, there is no way to query them, etc. Explicitly per RFC 4007 that defines zone identifiers, "The zone indices are strictly local to the node."). (Which the RFC 6874 mentions it's primarily expected these URLs to be intended for diagnostics and unlikely to be seen in the "wild" much less expected to ever be seen in Anchor tags in HTML documents.) (Even for diagnostics situations it sounds like it should be rare for instance that you might have different web servers on the same device running depending on which ethernet port or wifi device a message arrives on. Outside of routers and firewalls and crazy proxies that should be extremely rare, I would imagine. Device based zone identifiers are not going to replace Host header based Virtual Hosting any time soon I'd imagine, for example.)
AbacusAvenger 6y ago
The major problems I've run into with IPv6: - Some ISPs do not offer prefix delegation, so I have to use weird hacks like NDP proxying (I use ndppd for this). - My dhcpcd.exit-hook script is becoming a monstrosity to maintain the prefixes and routes for two different ISPs. With NDP proxying I need to have routes with metrics defined or else the LAN-side IPv6 global addresses are inaccessible to the outside world. I also need to maintain route advertisement configs for these prefixes via either radvd or dnsmasq (and need to restart the relevant services when those prefixes change). - Prefix deprecation route advertisement (i.e. when one global address prefix is no longer valid because that ISP went down) is difficult to implement properly. dnsmasq refuses to advertise a prefix (even with 0 lifetime to mark it deprecated) if there isn't an address for that prefix on an interface -- and tools like dhcpcd will remove those addresses automatically when the WAN-side interface goes down or the RAs expire, etc. radvd can deprecate all advertised prefixes on shutdown/restart, but that's not entirely desirable either. - Multihoming has no truly good solution right now. If you advertise two different global network prefixes (e.g. for different ISPs), then the individual client nodes decide which source address to use via the "longest common prefix" match (RFC 6724). This implicitly decides which ISP their outbound traffic will go through. The problem is that these individual clients are poorly placed to make those kinds of route decisions. With the two ISPs I have, some remote hosts exhibit better behavior (i.e. higher raw throughput, lower loss, lower latency, whatever) with one network or the other. With IPv4, I am using NAT and doing load balancing across the two ISPs (round robin selection basically). I also have some hard rules on the IPv4 NAT side about which network to prefer for specific remote addresses. With IPv6, I could do the same approach (via IPv6 ULA + NAT), but that defeats the main advantage of IPv6 where everything can have global addresses. - Debugging IPv6 problems can be a pain, because you have to check several more moving parts than with IPv4. Route advertisements, neighbor advertisements, DHCPv6, routing tables, IGMP/multicast snooping (which on some NETGEAR switches will drop IPv6 multicast traffic necessary for advertisements), etc.
- bb88 6y ago
  I would find a blog post going into depth about these issues enjoyable reading frankly.
- Arnavion 6y ago
djhaskin987 6y ago
I don't get why people keep advocating for IPv6, when it has all the adoption of the Dart Programming Language. It's obviously not working for a majority of businesses, or they would have adopted it. We just need to create an IPv7, which is just IPv4 with 64 bits of address space. I don't get why this is such a hard concept for people to swallow. IPv4 works fine, we're comfortable with it, we like it, let's just make it bigger. We can even make the new system backwards compatible. 0.0.0.0.127.0.0.1 is still localhost, for example. "But that's so hacky", you say. "We need to fix the old standard." This is what Intel said with its Intel 64 Itanium processor. Break with the old instruction set and make it better. AMD came out with Opteron[1], a hacky extension of the x86 ISA but for 64 bit. Backwards compatible. Swept the market. It's why your binaries are compiled to "amd64" now. Yes, IPv4 has quirks, and those quirks are well understood and lots of code exists now to deal with them. Let's not find out all the quirks of a new system the hard way for seemingly little benefit. 1: https://www.eweek.com/pc-hardware/64-bit-intel-vs.-amd https://www.eweek.com/pc-hardware/64-bit-intel-vs.-amd
- M2Ys4U 6y ago
  >I don't get why people keep advocating for IPv6, when it has all the adoption of the Dart Programming Language. I'm sure Dart would be absolutely over the moon to have 33% adoption.[0] [0] https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
- mprovost 6y ago
  Totally agree. Most people seem to assume that v6 is inevitable just because it's a standard. But its adoption is so low and has taken so many years that it's entirely possible that it will just become irrelevant and an evolutionary dead end. The history of tech is littered with abandoned standards that were replaced with something better. Ethernet was supposed to be replaced with ATM...
- mnd999 6y ago
  Not a good idea. It’s still a new protocol so you still have to build support for it. You’d have to fix all the software again to understand ipv7 and you have to start again from zero adoption. And what you get is as you state worse than ipv6 which is already widely adopted.
knorker 6y ago
This article boils down to "this is different! I don't like different even if it does solve HUGE problems". I love NPT. Complex NAT over tunnels and shit is an absolute disaster. NPT makes everything easy to troubleshoot and enables many solutions that IPv4 just cannot even touch. And also, if you really want IPv6, it's there. IPv6 works just fine with NAT if you believe that's best for you. "I'll never run IPv6 because it's different!" is a closed mind, and is just choosing to not even try to solve problems. What's your alternative? Just run IPv4 forever? Ugh. Awful.
- kempbellt 6y ago
  > "I'll never run IPv6 because it's different!" is a closed mind, and is just choosing to not even try to solve problems. Bit of a straw-man argument here. IPv6 is intimidating to work with, even for experienced engineers, but I don't believe that "just because it's different" is the reason that people don't like working with it. IPv6 solves some real problems with IPv4, but also adds a lot of non-intuitive standards to an already complex system. On your point about "NPT better than NAT, so IPv6 = superior!" - which I don't instinctively agree with, it's just different. The fact is, NAT still exists and will for a long time. It's so commonplace that almost every house and office in the modern world that has internet uses a NAT gateway. People generally understand what a LAN is and can differentiate between a LAN and a WAN (or "the internet"). Even high school kids can set up LAN parties with little difficulty. Telling people that "Hey, all that stuff you've know about the internet, well, it's still going to exist, but also we are going to throw a new standard on top of it that is suuuuper non-intuitive to work with but it makes things awesomer because, just take my word for it!! If you don't like it, you're just closed minded" is extremely closed minded... Also, try telling your friend over the phone, "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade: NO 8a DEEE EEE. Not C E... Ugh....nevermind" IPv6 is awesome in many ways, but it comes with a lot of frustrations to work with. Which I believe the author covered pretty well.
  - est31 6y ago
    > "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade: NO 8a DEEE EEE. Not C E... Ugh....nevermind" IMO ipv6 would have gotten far more adoption had they used a different assignment scheme: * Turn every ipv4 assignment into an ipv6 assignment by zero-extending to the left, i.e. 72.217.16.142 becomes ::72.217.16.142 * New addresses come from a new assignment ::2a00:0000:0000/96 which contains as much as the ipv4 space. So new addresses look like ::2a00:72.217.16.142. A little bit messier than ipv4, but still tidy mostly. In fact, this address syntax is a valid syntax variant of ipv6 addresses. These addresses are just not assigned today. Had we used this scheme instead of the current one with its extremely long addresses, we'd have had far greater adoption than now. Note: yes I'm aware of slight incompatibility issues between ipv6 and ipv4, like higher minimum MTU values of ipv6. I'm not suggesting a translation of ipv4 to ipv6 here, the hosts would still speak the two different protocols, but the assignment would match the ipv4 assignment.
parliament32 6y ago
>anything from 127.0.0.0 to 127.255.255.255 all mean the exact same thing Uhh no they don't. They're all unique addresses that can be explicitly listened on and connected to.. they just have to be routed to your lo interface by spec.
manuel_w 6y ago
If I understand certain parts of this article right, it suggests that IPv6 could in fact replace both the Network Layer (IPv4) as well as the Data Link Layer. Is this correct? Has anyone put this into practice? Imagine that we lived in such a world: wifi repeaters would just be IPv6 routers. So would wifi access points. So would ethernet switches. So would SDN. ARP storms would be gone. "IGMP snooping bridges" would be gone. Bridging loops would be gone. Every routing problem would be traceroute-able. And best of all, we could drop 12 bytes (source/dest ethernet addresses) from every ethernet packet, and 18 bytes (source/dest/AP addresses) from every wifi packet. Sure, IPv6 adds an extra 24 bytes of address (vs IPv4), but you're dropping 12 bytes of ethernet, so the added overhead is only 12 bytes - pretty comparable to using two 64-bit IP addresses but having to keep the ethernet header. The idea that we could someday drop ethernet addresses helped to justify the oversized IPv6 addresses. It would have been beautiful. Except for one problem: it never happened.
kempbellt 6y ago
IPv6 is a crux example of the tradeoff between security and convenience. I understand a lot of the pros of it, and I like them, but... The protocol is certainly much less human-brain-friendly, which gives points for security, but kills in the area of convenience - even for experienced engineers. As someone who frequently manages networks professionally and personally, I constantly need to look up information on the how the address hashing works, CIDR block ranges, short-hand notation, etc, etc...etc (because there is a lot). It's really added a hinderance to my workflow and makes typical network configuration take much longer than it would have before. It was easy for me to differentiate between LANs and WANs, subnets, etc in IPv4-land because the address space is much more intuitive to work with. CIDR block notation for IPv4 takes a minute to get used to (for new people), but it's easy to learn quickly and understand the ranges of your networks, or at least get a feel for it. Even after working with IPv6 for over a year, I still do not have an intuitive feel for how many addresses or what address range a CIDR block contains - which is extremely useful for debugging issues. If I can look at an IPv4 address in a log, I can immediately track down what subnet/machine had the issue and dig into the issue. IPv6 requires extra steps, and a lot of them. Naturally, NAT became a thing for IPv4. I don't know if it was originally introduced as a firewall mechanism or to cut down on publicly used IPs, but it works well for both. IPv6 circumvents the need for NAT, but then we have NPT, which is also unintuitive. Numbers are much more human friendly, as time has shown. It's easy to understand 127.x.x.x and 192.x.x.x are common prefix to local networks and I think that most people who have worked with computers at all have some understanding of what a "local" network is, but even after reading the article, my brain says "any IPv6 address that starts with an f is probably a special one, but I don't know why, just assume it means something and I'll have to do some Googling about 'prefixes' to figure it out". I like some of the pros of IPv6, and maybe after another year of usage it might feel more intuitive, but right now it comes with a serious learning curve and anytime I need to work with it, I get an instant headache. Also, have you ever looked at one screen to mentally grab an IP address and then needed to type it into another? Or asked a coworker for the machine's address so that you can take a look? Get used to using copy-paste a lot, because there's no way that you can glance at a screen for 2 seconds and mentally go, "aaah. Just need to ssh user@aksj:dfja:skja:sviw:eijf:000i:hate:00my:life....easy peasy"
- 6y ago
_trampeltier 6y ago
IPv6 might be a nice thing for companys. But at home you don't have a static IP. With IPv6, I get a new address every 24 hours from my provider. The devices always change last part of the address because of privacy. How can you write firewall rules to a such network.
- Olipro 6y ago
  By any combination of assigning static IPv6 addresses, organising devices into separate L2 links (VLANs) and firewalling by IP prefix, rather than the entire /128.
fulafel 6y ago
"IPv6 uses NPT, where you can transform one prefix into another prefix." What? No, NPT is a nonstandard experimental hack that's in no way part of IPv6 or supported by any standards track IETF protocols. "IPv6 was a draft in 1997(!), and became a real Internet Standard in 2017" The draft part of the claim is false, the basic IPv6 RFCs came out of draft and were published as standards track RFCs in 1995 eg https://tools.ietf.org/html/rfc1883 https://tools.ietf.org/html/rfc1883 / https://tools.ietf.org/html/rfc1884 https://tools.ietf.org/html/rfc1884 and then subsequent revisions in 1998 and 2017.
- djhaskin987 6y ago
  RFC = "Request For Comment", not actual standard. It's just when RFCs are published, generally people start immediately implementing them as if they were.
  - fulafel 6y ago
    The RFC publication series is where all kinds of IETF documents are published, standards or not. Having a RFC number doesn't mean that a document is or isn't standards track. IOW all IETF standards are RFCs, but not all RFCs are standards or proposed standards. The "request for comments" title of the series does remind us of the collegial and unbureucratic roots of the IETF, vowing to reject kings, presidents and voting & believing in rough consensus plus running code etc :) however in the standards track case there is no rfc number assigned to the doc in the draft phase, it's instead published in the separate internet-drafts directory by the working group and goes through all kinds of process and iteration before getting published as a proposed standard RFC. See eg https://en.wikipedia.org/wiki/Internet_Standard https://en.wikipedia.org/wiki/Internet_Standard
nikisweeting 6y ago
I'm surprised no one has linked to these two articles by @apenwarr yet, I consider them "the bible" for understanding IPv6 and why it was designed and implemented the way it was. - The world in which IPv6 was a good design: https://apenwarr.ca/log/20170810 https://apenwarr.ca/log/20170810 - IPv4, IPv6, and a sudden change in attitude: https://apenwarr.ca/log/20200708 https://apenwarr.ca/log/20200708
cblconfederate 6y ago
This is a great quick explainer for ipv6
pkulak 6y ago
Can't home routers, much like they all now have NTP by default, just have a firewall installed that by default blocks all incoming traffic unless it's a response to outgoing traffic? So, no prefix translation, everything has a real IP, and all incoming traffic still gets dropped on the floor by default.
- fulafel 6y ago
  Yes, that's how most CPEs work with ipv6 by default.
austincheney 6y ago
Whining. IPv6 is fantastic for two reasons: address space and no NAT. NAT, network address translation, means an artificial address space. That is all it means and it is limited by network size, even if that network is artificially addressed with nonrouteable addresses, which is small compared to PAT (port address translation). NAT is great if you want to hide from the world. It doesn't mean you have privacy. Everything can still leak out. It just means the outside cannot see you without a tunnel. In many way that actually hurts privacy because you cannot establish a point-to-point tunnel without a third party and that third party must have access to the transmission headers. NAT was never created for privacy or security. NAT and PAT were only created to extend the range of IPv4 addresses. In the web there is no point-to-point communication such as client-to-client. The web is only client-server. You make a request to the server, which establishes a tunnel and the server talks back with a response that follows the request in reverse. If you wanted to talk with a peer you would do so through a server. For example if you use iMessenger, Signal, or whatever you aren't directly talking to people. You are talking to a server and that server shares your messages with your friends. The server sees everything... no privacy. Even with end-to-end encryption you still relay everything through a server that knows half of every conversation. IPv6 does not have NAT. That is great. The security benefits of an artificial address space that isn't routed are still available in IPv6. This is from a range of addresses called link local that do not route. Since there is no NAT in IPv6 if you can see an outside computer that outside computer can see you equally. That means you don't need a server to chat with your friends. Just directly talk to your damn friends. No tunnel needed. End-to-end encryption can be as simple as HTTPS. You cannot get that with IPv4, largely due to NAT. Yes, only nerds care about privacy.... Well, no. If privacy is the default and end-to-end encryption is always the default you can do things and share things you would NEVER in a million years put on Facebook, because its actually private, like giving a USB hard drive directly to your life partner. That is a massive new set of business opportunities that scares the shit out of people on today's web (for good reason).
reanimus 6y ago
The complaints about allocating a percentage of IPv6 addresses for certain usages are a bit silly. Yeah, 1.271% of the addresses are private addresses. IPv6 has 340 trillion trillion trillion possible addresses. IPv4 has 4.2 billion.
ohgreatwtf 6y ago
we need a new standard for human design that emphasizes the simplicity and intuitive aspects. In all places. Laws, programming, etc. If it is too complex to readily use it and easily debug it, then it is bad. It is bad not because it is complex, but because it inserts overhead, and overhead in time spent solving problems is always exponential. I am for the idea of using ipv6 as a sort of nation-level NAT for big corporations and countries to expose part of a private address space over a section of ipv4, while each country gets most of ipv4 to itself along with a section where you can route to other countries, in exchange for a small fee. Say 30% of the ipv4 space is globally shared by everyone and the rest is local to your own country. Also IOT local mesh networks all would be on auto configured tunnels with only certain gateway systems hard coded- systems you can block at your router. That’s the most sensible solution. It will be a real shame if it is not the reality. Arrogance and “hurr durr i’m so smart and i spent 40 hours this week setting up this brilliant ipv6 network topology for my company that will require five manuals to fully explore and retain me in my job for a minimum of 10 years to keep it all working”- meanwhile the rest of us will suffer. The biggest most canally disgusting thing about ipv6 is that it will render dns based ad blocking a thing of the past. If you want any kind of blocking you will have to go with curated WHITELISTS, instead of blacklists. And that may be more secure but it will also be a lot more work, which, again, the ipv6 nerds will love to do but will present a hassle for the rest of us. You won’t be able to manually check the dns list anymore. you will simply have to accept that the overhead and the security risk of trusting all of the 35 million addresses in the whitelist is a cost you are willing to accept. Say no to ipv6. I have already blocked it on everything and will never adopt. it is the ethanol of internet addressing.
- Dagger2 6y ago
  You say you want simplicity, then you suggest a "nation-level NAT" that includes keeping v4 alive with overlapping allocations in multiple countries, NATing into v6 to talk to other countries, apparently for a fee that will need to be paid somehow. This is not simple, and is certainly not the most sensible solution. The simple and sensible solution is to just use v6. > The biggest most canally disgusting thing about ipv6 is that it will render dns based ad blocking a thing of the past. This claim is completely nonsensical. DNS-based ad blacklisting works just fine in v6. None of the problems you list with it exist. I suggest you unblock v6 and use it. You'll find it works the same as v4 does, just without the added complexity of NAT.
withinboredom 6y ago
Y’all are lucky. No ipv6 where I live. I’ve only gotten to play with it locally and occasionally on cloud servers. Don’t see the point in it.
- Dagger2 6y ago
  v4 isn't big enough to handle the current, let alone future, scale of the internet. The point of v6 is to be big enough to do that.
deleted 6y ago
[deleted]

146 points by whereistimbo 6y ago

Not very convincing. Addresses cannot be handled by humans? The same is true for all modern computing. Intels CPU has several prefetch queues, some with more than 200 entries. Who can handle this? Well, not even Intel's engineers as Meltdown and the later discoveries have shown. Have you looked how a GPU works? Recently there has been discussion that Kubernetes depends on 200 libraries. The list goes on and on. That said, he might or might not have some point in the address translation section. But not being an expert in IPv6, he has wasted his trust by useless complaining before he gets to the possible beef.

Arnt 6y ago
AIUI, address translation isn't how it's done. Rather, if you want the hosts on a network to be reachable under some other prefix, you advertise that other prefix (in addition) and then the hosts have an extra address. IPv6 hosts have lots of addresses. v4 needs to scrimp, v6 doesn't.
- jachee 6y ago
  The analogy that really drove home how many IPv6 addresses there are is this: Take every known star in the sky today, give each of them a full IPv4-sized /32 address space, and you'd still have IPv6 space left over. No need to scrimp, indeed!
  - bb88 6y ago
    Not sure why you're being downvoted here, since the point is valid. I calculated the number of IPv6 addresses per square meter of the earth's surface and got a similarly large number.
    - usr1106 6y ago
      So what would have been an ideal length for you? I think the fixed separation into centrally and privately managed halves is a good idea. 48 + 48? Would that stop your critique? I guess that would cause all kind of alignment issues. 64 + 32? Probably enough, but the gain seems marginal to me.
      - bb88 6y ago
        To be honest, other than running out of space, the length of an IP address has never truly mattered, because you don't typically use the IP address to access microsoft.com, e.g. Also routing uses subtrees, so we could have had just grown IPv4 with an extra 4 octets too. Does every cold virus need an IP address, no. But on the other hand it might make sense to give every planet and asteroid in the solar system one.
    - Arnt 6y ago
      He may be downvoted because counting that is a bit disingenious. The central concept in v4 is an interface, which has a 32-bit address and of which a host tends to have one. The central concept in v6 is a network, which has a 64-bit address and which may be populated by one or many hosts. The number of /64 network addresses per m² of the planet is also a large number, I'm sure. (That it is a large number is intentional, in order to permit simple routing even when that simplicity leads to lower addressing density.) But counting that is honest in a way which counting /128 addresses isn't.
himinlomax 6y ago
> Not very convincing. Addresses cannot be handled by humans? Yeah it's the weakest critique against IPv6. There's plenty to complain about, this is just pointless.
theon144 6y ago
>The same is true for all modern computing. Yes it is. Is this a beneficial trend? If not, is it not worthy of critique?
- usr1106 6y ago
  Not necessarily. I am also sceptical of the extreme optimization tricks done for Intel architecture CPUsm because they lead to security vulnerabilities. A simpler RISC style ISA would be preferable. And of 4K displays, because the complications it brings for (Linux) desktops and more importantly the increased power consumption it causes for irrelvant benefit for the majority of users. I could continue the list, I still enjoy to run Linux on a laptop with 2G of memory (not for building Yocto, but for basic web browsing and doing script programming at least.) Incidently it has no problems with IPv6. But losing that many words about addresses not to be used by humans anyway seems out of proportion for relevant critique.

Lammy 6y ago

> Well, by breaking it again, naturally. To connect to a raw IPv6 address, you wrap it in square brackets. To connect to 2607:f0d0:1002:51::4 directly, that’s http://[2607:f0d0:1002:51::4]/ http://[2607:f0d0:1002:51::4]/ Why is this a thing?!. It's even sillier in Windows Explorer where UNC IPv6 paths are the IPv6 address "with the ':' characters replaced by '-' characters followed by the '.ipv6-literal.net' string": https://docs.microsoft.com/en-us/windows/win32/api/winnetwk/nf-winnetwk-wnetaddconnection2a#remarks https://docs.microsoft.com/en-us/windows/win32/api/winnetwk/... For example, I mount my NAS as "\\fd13-c001-7232-1-13--36.ipv6-literal.net"! https://i.imgur.com/waLJRFf.png https://i.imgur.com/waLJRFf.png

lolc 6y ago
I bet your NAS has a mDNS name. If it doesn't, configure it!
- Lammy 6y ago
  It’s a point-to-point 25Gbit fiber link directly between the two machines, not switched like the rest of my network, and I didn’t feel like complicating it more than that :)

PikachuEXE 6y ago

I noticed this article talks about IPv6 version NAT - NPT ``` Remember, this will blindly just swap prefixes in and out. Gone are the days of “only the traffic I explicitly create a rule for can get in”. See, now, just adding that one step will, be default, expose your entire network! You now need firewall rules to block what you don’t want and add explicit allows, this time manually as an additional step. This is more of a “default pass” routing — unless I tell you not to, let it through. ``` This seems like a great security concern Would be good to know if this statement is accurate I might consider disabling IPv6 if this is true

redis_mlc 6y ago
If you're concerned about security, yeah I would disable IPv6. Until all firewall and router mfgs. re-QA every little feature added for IPv6, you don't really know what your equipment is doing.
- redis_mlc 6y ago
  Can somebody explain what the downvotes are for? Are you IPv6 fanbois? Have you audited all the firmware and software on your firewalls and routers?
  - alphager 6y ago
    Have you audited the IPv4-codepaths? Your comment contained no information above "I don't trust it".
    - redis_mlc 6y ago
      > Have you audited the IPv4-codepaths? Are you for real? There's been decades of production experience with IPv4 and does mostly what's expected. Of course IPv6 shouldn't be trusted. New software has bugs. That applies doubly for networking code. Get your fuzzers started ...
- josho 6y ago
  To provide a data point to your assertion my brand new tp-link wifi router has a setting for ipv6 firewall, but it does nothing. Yes all my home devices are exposed to the public internet. Yikes! The tech support team even confirmed that ipv6 firewall support is coming ‘soon’. Meanwhile my ASUS router’s ipv6 support is broken as well for dns configuration. So, yeh it is still early days for consumer ipv6 adoption.

diegocg 6y ago

>Even though the entire “special” address assignments are exactly 1.271% of the entire IPv6 address space, we’re still allocating giant swathes of addresses. History repeats itself, you can see that right here. So what? The whole point of IPv6 is that wasting address space like that is irrelevant - there is going to be enough space regardless

mikeyjk 6y ago
I listened to a podcast where Geoff Huston argued that the address space of IPv6 when compared to IPv4 isn't going to give us as much runway as people suspect: https://pca.st/episode/a1df7379-853f-4b5b-af5d-fcb6ad7e1390 https://pca.st/episode/a1df7379-853f-4b5b-af5d-fcb6ad7e1390 Can anyone let me know if he is wrong? It really challenged my perception that IPv6 seriously future proofed the need for a larger address space. "By the time we run out of v4 with NATs, v6 will offer us no more bits"
- kstrauser 6y ago
  Can you give a summary? ISPs would have to assign a /32 prefix to every connection before we'd be in the same boat as IPv4, but my ISP gives out /64 prefixes (and so uses a 4-billionth as much of the address space as IPv4 does).
  - magicalhippo 6y ago
    Didn't have time to listen to the whole thing yet, but from what I gathered it's two things: the lower 64bits of the 128bit addresses doesn't count (due to privacy), and that carrier-grade NAT might go much further than what some people think. If all you want to do is to watch YouTube and check out Instagram, and Google and Facebook have servers in a rack "nearby" (in the network sense) ala what Netflix does, then you don't need a globally unique IP to talk to them.
    - Dagger2 6y ago
      If we're going to talk about "need", then you don't even need a computer. You could walk over to the rack and watch the yougram on its management console. But there are advantages to having a computer. Similarly, there are advantages to doing your networking right, and that means globally-unique IPs.

ktpsns 6y ago

One problem I rarely read about IPv6 is the mixing of responsibility levels. Sure, we have 2128 IPv6 addresses or so because nobody knows how internet infrastructure will look like in 30 years (maybe internet node virtualization is gone mad). But it's my feeling that the IP address should only be an address and not that half-mixed anonymity-related thing. See, a general problem I see with IPv6 and all the protocols around is their enormous complexity. As a hobbyist in the last decades, you could learn about IPv4 and DHCP in a couple of afternoons. It was simple the same way as HTTP1 was simple compared with HTTP2. Complexity means the learning curve is enormous and in the end only a fraction of experts will understand. My personal opinion is that complexity in computing will evventually kill everything: security dies first, innovation comes last. Sorry for this rant. I assume the IPv6 design was carefully crafted by gifted and highly skilled people. We'll use it anyway, some day :-)

lxgr 6y ago
> As a hobbyist in the last decades, you could learn about IPv4 and DHCP in a couple of afternoons. The same is true for IPv6! Granted, beginner-friendly documentation is a bit harder to find, but I was able to set it up for my home network through OpenWRT in a couple of afternoons as well. In the process, by necessity I also learned something about setting up local DNS properly, which in the end has been very beneficial also for IPv4 hobbyist use cases. The comparison with HTTP1 vs. HTTP2 seems a bit unfair – it was never possible to write plain IPv4 packets to the network via Telnet/nc. And if you're talking about the availability of tooling: Don't forget that IPv4 is several decades more mature than IPv6 :)
- ktpsns 6y ago
  All your points are valid. I have to be honest, I was always scared off the sheer amount of protocols and ressources around IPv6. It felt that I have to deal with anycast, self-organized networks, anonymous embedding of MAC addresses, some NAT-replacement, etc. when I touch IPv6. It's probably not true and one can start with IPv6 also in a simpler fashion. Maybe I'm also just too much used to ifconfig and nat tables that the switch feels hard. The comparison of HTTP1 vs. HTTP2 is in fact only valid on a level of complexity. As an hobbyist, I'm actually quite excited of finally abandoning NAT and being able to reach my Raspberry at home from anywhere in the net. This dream is still far away, given that many places don't have access to IPv6 (without a tunnel).

viraptor 6y ago

> With NPt, you cannot do this, you’d have to have an additional device like a layer 7 proxy (like HAProxy) to take in everything and send it to the correct destination This is mostly incorrect. Yes, NPT can't do this. No, you don't need an additional proxy. All the usual methods work, they're just not called NPT. On linux MASQ and REDIRECT targets work on ipv6. You can change addresses and ports exactly the same way you'd do it for ipv4. There are other wrong things in this rant too. I'm curious if the author ran into many issues while implementing ipv6 or just doesn't like the idea in general. The problems and some solutions seem very contrived and there are better ways to solve them.

lxgr 6y ago

Much of this boils down to "IPv6 sucks because it's so different from IPv4", which has never been a very convincing criticism to me. The conclusion of "It's hard to memorize or type plain IPv6 addresses" has always been "I guess I need (m)DNS" for me, not "wow, IPv6 is bad". And some years later, I'm extremely happy I don't have to memorize even local IPv4 addresses anymore – mDNS together with a proxying/caching local router works that well. Regarding the "unnecessary" changes (i.e. everything besides just adding 96 more bits to every address): When implementing a new IP protocol version literally touches every single device on the network (at some point), why not use that opportunity to revisit some of the historically grown cruft?

magicalhippo 6y ago
For me IPv6 sucks because it doesn't really solve my problems in a better way, and instead seemingly introduces a lot more fragility and complexity. I still have to mess with the firewall to open ports, not much different from doing IPv4 NAT as my router software (pfSense) automatically creates firewall rules tracking the port mapping. Except it is worse, because my firewall software don't track IPv6 changes so breaks whenever the device gets a new IP (say new prefix). When exposing services to the internet it's even more PITA since each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP. IPv6 on the LAN is quite a pita due to the massive "random" prefix, gone are the days of easy addresses like 10.0.0.12. Yeah I guess I could just use the local address space but what does that really bring over the IPv4 that I know? And then there's the software that just doesn't follow the times. My router just doesn't handle getting a new prefix. Yeah OK the initial IPv6 wet dream was for an eternal prefix. But clearly that's been unrealistic for quite some time, and sadly not all software has caught up. I will admit that some of it is probably down to me learning more. But I struggle to find the motivation. There's no "killer app", just a lot of pain so far.
- morsch 6y ago
  When exposing services to the internet it's even more PITA since each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP. Presumably because you configured the forwarding on the router? I mean, that should still be possible, right? Set up a name for the routers IP, and have it forward the connections statically. IPv6 on the LAN is quite a pita due to the massive "random" prefix, gone are the days of easy addresses like 10.0.0.12. Or just use the hostname? Sometime a couple of years ago, local names just started working, sort of on their own. My Synology is nas.local, Linux boxes are reachable using their configured hostname, even my elderly printer shows up as vigor2.local.

danbmil99 6y ago

-4 ftw

eddyg 6y ago

One actual problem not mentioned in the article is that, by default, SLAAC embeds the MAC address of the interface when generating the autoconfigured IPv6 address. As an example, if an interface’s MAC address was `01:23:45:67:89:ab`, the lower 64 bits of the SLAAC assignment (the “host” part) results in an IPv6 address of `:123:45ff:fe67:89ab` (the extra `ff:fe` bytes are constant, making it more obvious the surrounding bytes are likely a MAC address). This has huge implications to privacy, since even as you roam and change networks (and thus the upper part of the address changes), the lower 64-bits stay exactly the same, making it easy to “follow” a device from session to session and site to site. This was addressed by an update to SLAAC: “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” in RFC 4941[0]... but it has to be explicitly enabled on a per-interface basis. A great thing about this feature is that these random, private addresses timeout and become “deprecated” (and a new random address gets assigned to the interface and used for new connections), making it harder for third-parties to track connections over the long-term. Unfortunately, address privacy is a SLAAC thing, so if you want the benefit of registering a device on your network (via DHCPv6, so you can actually correlate IPv6 traffic on your network to a device), you don’t get the benefits of SLAAC’s privacy extensions. [0] https://tools.ietf.org/html/rfc4941 https://tools.ietf.org/html/rfc4941

admax88q 6y ago
> This was addressed by an update to SLAAC: “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” in RFC 4941[0]... but it has to be explicitly enabled on a per-interface basis. That's not really a problem with ipv6 so much as a problem with defaults. Nothing stops distributions from enabling the privacy extensions by default, and I'm sure many already do.
Dagger2 6y ago
I would argue this is barely the default these days. Windows, OS X, and on the Linux side network-manager, dhcpcd, systemd-networkd etc all have privacy addresses enabled by default. Many OSs/distros also have RFC7217-style addresses enabled by default too, so even the SLAAC base address doesn't contain the MAC on those. DHCPv6 does actually implement temporary addresses too. Support for that is legitimately rare though.

audunw 6y ago

As a networking novice that article actually made me feel positive about IPv6 during most of it. I feel like maybe firewall based security is a bit of an outdated model. It’s going to take a while to figure out how to secure our networks/devices well, but it feels like a model that pushes more of the configuration to the device will be more secure and more universal (since more and more devices will be LTE connected) The model where you by default have access to everything inside the network if you can just get a connection behind the firewall never seemed all that great to me. If we can’t assume that any connection from the local network is authorized anymore, maybe it’ll push us to make servers/services more inherently secure, and accept/reject connections based on actually authenticating the user/device connecting to it. But then again, I’m not a professional so I may be wrong.

benc666 6y ago
A layered approach to security (onion model) is the only sane approach because any given layer will always have flaws. The notion I get from the article is that security becomes a huge problem when every node is exposed to almost every other node by design intent. That's why NAT is mentioned several times.
- djhaskin987 6y ago
  Exactly. Security at the endpoint level, rather than the firewall level, means that those that build those applications are in charge of security. There is no way my multi-business-unit company is going to solely trust developers with its security and compliance story. It's going to hire people whose job it is to secure the network as well. Given that these people don't even know all of the developers (or yet even their managers) inside this multi-business business, the only good thing those people have is firewalls and traffic inspection at large.
  - bb88 6y ago
    You're still going to have a firewall, it just won't be NAT based.

Cyder 6y ago

Hasnt the privacy issue been helped by using temporary ipv6 addresses? This is why my Windows machines have 3 v6 address with only one being permanent and the other 2 being called temporary? The temporary address did change after a restart. I checked my Linux VMs and none of them have this security feature yet.

moviuro 6y ago
> I checked my Linux VMs and none of them have this security feature yet. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/ip-sysctl.rst?id=b38e7819cae946e2edf869e604af1e65a5d241c5#n2053 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- kstrauser 6y ago
  Yep, and while I'm too lazy to dig into detailed kernel histories, that's been in there for at least 9 years now: https://home.regit.org/2011/04/ipv6-privacy/ https://home.regit.org/2011/04/ipv6-privacy/ Short version: echo "2">/proc/sys/net/ipv6/conf/eth0/use_tempaddr turns on privacy extensions on eth0, and makes them the preferred addresses.
  - MayeulC 6y ago
    Also, I think this is enabled by default in NetworkManager, which takes over that kernel option when in use. On servers, not using a temporary address is a sane default.
    - kstrauser 6y ago
      Yeah, that seems appropriate.

commandlinefan 6y ago

> Some devices might have a high-MTU link on one end, and a lower MTU link on the other. Good lord, is this really still the case 1/5 of the way through the 21st century?

kitteh 6y ago
Yes. Which raises the question why don't we have something to detect/mitigate this.
- cesarb 6y ago
  In my opinion (with hindsight), the IPv4/IPv6 model of "drop packets which exceed MTU" as the alternative to fragmenting packets was a bad choice. It would have been much better to take a third option and truncate the oversized packet. That would avoid both the bad effects of fragmentation (slow path in the routers, memory use in the receivers, non-initial fragments which lack the higher level headers making it a pain for firewalls) and the bad effects of dropping (waste of the bandwidth to send the dropped packet, broken firewalls discarding the ICMP message, CPU use in the router to send the ICMP message).
  - Olipro 6y ago
    Except in practice this is useless because you're now transmitting what is basically a corrupted packet. For this to work, L4 protocols would need to be completely redone to consider and work with this concept. Also, what is actually meant to happen is that an ICMP(v6) packet too big message is supposed to be sent back to inform the sender that they need to reduce the packet size. Unfortunately, with the pervasiveness of idiotic firewall configurations that blanket block ICMP, this falls apart which is why we have to deal with ugly hacks like TCP MSS mangling.
- toast0 6y ago
  There's path MTU blackhole detection. See RFC 4821. This or similar systems are enabled in most mainstream operating systems (but not Android, because Google would rather replace TCP with TCP over UDP than fix TCP with existing fixes). Like cesarb's sibling comment, I think router driven packet truncation would be useful. IP fragmentation is generally problematic and router driven fragmentation was eliminated from IPv6, but truncation with in-band indication would work a lot better. For TCP, the kernel on the receiver of a truncated packet could send an in-band ack of the received bytes, with a tcp option indicating the effective MTU. For UDP, it would be a bit more complicated, you would need to alter the recvmsg syscall to provide both the original size and the received size, and transmitting that information back to the sender would be protocol specific of course. The sender would then either trigger IP fragmentation to appropriate sizes or some protocol specific fragmentation.

tashian 6y ago

The "zone index" they mentioned can make for even more unwieldy URLs than described here. A browser doesn't have to accept: http://[fe80::1ff:fe23:4567:890a%eth0]/ http://[fe80::1ff:fe23:4567:890a%eth0]/ Because of the ambiguity around '%', the browser may require: http://[fe80::1ff:fe23:4567:890a%25eth0]/ http://[fe80::1ff:fe23:4567:890a%25eth0]/ I'm not sure how common this would actually be—neither of these URL forms are valid in Firefox or Chrome on my machine today. Source: https://tools.ietf.org/html/rfc6874#section-3 https://tools.ietf.org/html/rfc6874#section-3

WorldMaker 6y ago
As the article points out the zone identifiers are primarily for making sure you are sending packets out on the right device (network adapter) and extremely rarely play into receiving data, so it would be extremely uncommon/unlikely to see zone identifiers in URLs because presumably they would only make sense, pending some unspecified future usage, for diagnostics on a single device (as the zone identifiers mostly don't "leave" a specific device; they aren't advertised externally, there is no way to query them, etc. Explicitly per RFC 4007 that defines zone identifiers, "The zone indices are strictly local to the node."). (Which the RFC 6874 mentions it's primarily expected these URLs to be intended for diagnostics and unlikely to be seen in the "wild" much less expected to ever be seen in Anchor tags in HTML documents.) (Even for diagnostics situations it sounds like it should be rare for instance that you might have different web servers on the same device running depending on which ethernet port or wifi device a message arrives on. Outside of routers and firewalls and crazy proxies that should be extremely rare, I would imagine. Device based zone identifiers are not going to replace Host header based Virtual Hosting any time soon I'd imagine, for example.)

AbacusAvenger 6y ago

The major problems I've run into with IPv6: - Some ISPs do not offer prefix delegation, so I have to use weird hacks like NDP proxying (I use ndppd for this). - My dhcpcd.exit-hook script is becoming a monstrosity to maintain the prefixes and routes for two different ISPs. With NDP proxying I need to have routes with metrics defined or else the LAN-side IPv6 global addresses are inaccessible to the outside world. I also need to maintain route advertisement configs for these prefixes via either radvd or dnsmasq (and need to restart the relevant services when those prefixes change). - Prefix deprecation route advertisement (i.e. when one global address prefix is no longer valid because that ISP went down) is difficult to implement properly. dnsmasq refuses to advertise a prefix (even with 0 lifetime to mark it deprecated) if there isn't an address for that prefix on an interface -- and tools like dhcpcd will remove those addresses automatically when the WAN-side interface goes down or the RAs expire, etc. radvd can deprecate all advertised prefixes on shutdown/restart, but that's not entirely desirable either. - Multihoming has no truly good solution right now. If you advertise two different global network prefixes (e.g. for different ISPs), then the individual client nodes decide which source address to use via the "longest common prefix" match (RFC 6724). This implicitly decides which ISP their outbound traffic will go through. The problem is that these individual clients are poorly placed to make those kinds of route decisions. With the two ISPs I have, some remote hosts exhibit better behavior (i.e. higher raw throughput, lower loss, lower latency, whatever) with one network or the other. With IPv4, I am using NAT and doing load balancing across the two ISPs (round robin selection basically). I also have some hard rules on the IPv4 NAT side about which network to prefer for specific remote addresses. With IPv6, I could do the same approach (via IPv6 ULA + NAT), but that defeats the main advantage of IPv6 where everything can have global addresses. - Debugging IPv6 problems can be a pain, because you have to check several more moving parts than with IPv4. Route advertisements, neighbor advertisements, DHCPv6, routing tables, IGMP/multicast snooping (which on some NETGEAR switches will drop IPv6 multicast traffic necessary for advertisements), etc.

bb88 6y ago
I would find a blog post going into depth about these issues enjoyable reading frankly.
Arnavion 6y ago

djhaskin987 6y ago

I don't get why people keep advocating for IPv6, when it has all the adoption of the Dart Programming Language. It's obviously not working for a majority of businesses, or they would have adopted it. We just need to create an IPv7, which is just IPv4 with 64 bits of address space. I don't get why this is such a hard concept for people to swallow. IPv4 works fine, we're comfortable with it, we like it, let's just make it bigger. We can even make the new system backwards compatible. 0.0.0.0.127.0.0.1 is still localhost, for example. "But that's so hacky", you say. "We need to fix the old standard." This is what Intel said with its Intel 64 Itanium processor. Break with the old instruction set and make it better. AMD came out with Opteron[1], a hacky extension of the x86 ISA but for 64 bit. Backwards compatible. Swept the market. It's why your binaries are compiled to "amd64" now. Yes, IPv4 has quirks, and those quirks are well understood and lots of code exists now to deal with them. Let's not find out all the quirks of a new system the hard way for seemingly little benefit. 1: https://www.eweek.com/pc-hardware/64-bit-intel-vs.-amd https://www.eweek.com/pc-hardware/64-bit-intel-vs.-amd

M2Ys4U 6y ago
>I don't get why people keep advocating for IPv6, when it has all the adoption of the Dart Programming Language. I'm sure Dart would be absolutely over the moon to have 33% adoption.[0] [0] https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
mprovost 6y ago
Totally agree. Most people seem to assume that v6 is inevitable just because it's a standard. But its adoption is so low and has taken so many years that it's entirely possible that it will just become irrelevant and an evolutionary dead end. The history of tech is littered with abandoned standards that were replaced with something better. Ethernet was supposed to be replaced with ATM...
mnd999 6y ago
Not a good idea. It’s still a new protocol so you still have to build support for it. You’d have to fix all the software again to understand ipv7 and you have to start again from zero adoption. And what you get is as you state worse than ipv6 which is already widely adopted.

knorker 6y ago

This article boils down to "this is different! I don't like different even if it does solve HUGE problems". I love NPT. Complex NAT over tunnels and shit is an absolute disaster. NPT makes everything easy to troubleshoot and enables many solutions that IPv4 just cannot even touch. And also, if you really want IPv6, it's there. IPv6 works just fine with NAT if you believe that's best for you. "I'll never run IPv6 because it's different!" is a closed mind, and is just choosing to not even try to solve problems. What's your alternative? Just run IPv4 forever? Ugh. Awful.

kempbellt 6y ago
> "I'll never run IPv6 because it's different!" is a closed mind, and is just choosing to not even try to solve problems. Bit of a straw-man argument here. IPv6 is intimidating to work with, even for experienced engineers, but I don't believe that "just because it's different" is the reason that people don't like working with it. IPv6 solves some real problems with IPv4, but also adds a lot of non-intuitive standards to an already complex system. On your point about "NPT better than NAT, so IPv6 = superior!" - which I don't instinctively agree with, it's just different. The fact is, NAT still exists and will for a long time. It's so commonplace that almost every house and office in the modern world that has internet uses a NAT gateway. People generally understand what a LAN is and can differentiate between a LAN and a WAN (or "the internet"). Even high school kids can set up LAN parties with little difficulty. Telling people that "Hey, all that stuff you've know about the internet, well, it's still going to exist, but also we are going to throw a new standard on top of it that is suuuuper non-intuitive to work with but it makes things awesomer because, just take my word for it!! If you don't like it, you're just closed minded" is extremely closed minded... Also, try telling your friend over the phone, "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade: NO 8a DEEE EEE. Not C E... Ugh....nevermind" IPv6 is awesome in many ways, but it comes with a lot of frustrations to work with. Which I believe the author covered pretty well.
- est31 6y ago
  > "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade: NO 8a DEEE EEE. Not C E... Ugh....nevermind" IMO ipv6 would have gotten far more adoption had they used a different assignment scheme: * Turn every ipv4 assignment into an ipv6 assignment by zero-extending to the left, i.e. 72.217.16.142 becomes ::72.217.16.142 * New addresses come from a new assignment ::2a00:0000:0000/96 which contains as much as the ipv4 space. So new addresses look like ::2a00:72.217.16.142. A little bit messier than ipv4, but still tidy mostly. In fact, this address syntax is a valid syntax variant of ipv6 addresses. These addresses are just not assigned today. Had we used this scheme instead of the current one with its extremely long addresses, we'd have had far greater adoption than now. Note: yes I'm aware of slight incompatibility issues between ipv6 and ipv4, like higher minimum MTU values of ipv6. I'm not suggesting a translation of ipv4 to ipv6 here, the hosts would still speak the two different protocols, but the assignment would match the ipv4 assignment.

parliament32 6y ago

>anything from 127.0.0.0 to 127.255.255.255 all mean the exact same thing Uhh no they don't. They're all unique addresses that can be explicitly listened on and connected to.. they just have to be routed to your lo interface by spec.

manuel_w 6y ago

If I understand certain parts of this article right, it suggests that IPv6 could in fact replace both the Network Layer (IPv4) as well as the Data Link Layer. Is this correct? Has anyone put this into practice? Imagine that we lived in such a world: wifi repeaters would just be IPv6 routers. So would wifi access points. So would ethernet switches. So would SDN. ARP storms would be gone. "IGMP snooping bridges" would be gone. Bridging loops would be gone. Every routing problem would be traceroute-able. And best of all, we could drop 12 bytes (source/dest ethernet addresses) from every ethernet packet, and 18 bytes (source/dest/AP addresses) from every wifi packet. Sure, IPv6 adds an extra 24 bytes of address (vs IPv4), but you're dropping 12 bytes of ethernet, so the added overhead is only 12 bytes - pretty comparable to using two 64-bit IP addresses but having to keep the ethernet header. The idea that we could someday drop ethernet addresses helped to justify the oversized IPv6 addresses. It would have been beautiful. Except for one problem: it never happened.

kempbellt 6y ago

IPv6 is a crux example of the tradeoff between security and convenience. I understand a lot of the pros of it, and I like them, but... The protocol is certainly much less human-brain-friendly, which gives points for security, but kills in the area of convenience - even for experienced engineers. As someone who frequently manages networks professionally and personally, I constantly need to look up information on the how the address hashing works, CIDR block ranges, short-hand notation, etc, etc...etc (because there is a lot). It's really added a hinderance to my workflow and makes typical network configuration take much longer than it would have before. It was easy for me to differentiate between LANs and WANs, subnets, etc in IPv4-land because the address space is much more intuitive to work with. CIDR block notation for IPv4 takes a minute to get used to (for new people), but it's easy to learn quickly and understand the ranges of your networks, or at least get a feel for it. Even after working with IPv6 for over a year, I still do not have an intuitive feel for how many addresses or what address range a CIDR block contains - which is extremely useful for debugging issues. If I can look at an IPv4 address in a log, I can immediately track down what subnet/machine had the issue and dig into the issue. IPv6 requires extra steps, and a lot of them. Naturally, NAT became a thing for IPv4. I don't know if it was originally introduced as a firewall mechanism or to cut down on publicly used IPs, but it works well for both. IPv6 circumvents the need for NAT, but then we have NPT, which is also unintuitive. Numbers are much more human friendly, as time has shown. It's easy to understand 127.x.x.x and 192.x.x.x are common prefix to local networks and I think that most people who have worked with computers at all have some understanding of what a "local" network is, but even after reading the article, my brain says "any IPv6 address that starts with an f is probably a special one, but I don't know why, just assume it means something and I'll have to do some Googling about 'prefixes' to figure it out". I like some of the pros of IPv6, and maybe after another year of usage it might feel more intuitive, but right now it comes with a serious learning curve and anytime I need to work with it, I get an instant headache. Also, have you ever looked at one screen to mentally grab an IP address and then needed to type it into another? Or asked a coworker for the machine's address so that you can take a look? Get used to using copy-paste a lot, because there's no way that you can glance at a screen for 2 seconds and mentally go, "aaah. Just need to ssh user@aksj:dfja:skja:sviw:eijf:000i:hate:00my:life....easy peasy"

6y ago

_trampeltier 6y ago

IPv6 might be a nice thing for companys. But at home you don't have a static IP. With IPv6, I get a new address every 24 hours from my provider. The devices always change last part of the address because of privacy. How can you write firewall rules to a such network.

Olipro 6y ago
By any combination of assigning static IPv6 addresses, organising devices into separate L2 links (VLANs) and firewalling by IP prefix, rather than the entire /128.

fulafel 6y ago

"IPv6 uses NPT, where you can transform one prefix into another prefix." What? No, NPT is a nonstandard experimental hack that's in no way part of IPv6 or supported by any standards track IETF protocols. "IPv6 was a draft in 1997(!), and became a real Internet Standard in 2017" The draft part of the claim is false, the basic IPv6 RFCs came out of draft and were published as standards track RFCs in 1995 eg https://tools.ietf.org/html/rfc1883 https://tools.ietf.org/html/rfc1883 / https://tools.ietf.org/html/rfc1884 https://tools.ietf.org/html/rfc1884 and then subsequent revisions in 1998 and 2017.

djhaskin987 6y ago
RFC = "Request For Comment", not actual standard. It's just when RFCs are published, generally people start immediately implementing them as if they were.
- fulafel 6y ago
  The RFC publication series is where all kinds of IETF documents are published, standards or not. Having a RFC number doesn't mean that a document is or isn't standards track. IOW all IETF standards are RFCs, but not all RFCs are standards or proposed standards. The "request for comments" title of the series does remind us of the collegial and unbureucratic roots of the IETF, vowing to reject kings, presidents and voting & believing in rough consensus plus running code etc :) however in the standards track case there is no rfc number assigned to the doc in the draft phase, it's instead published in the separate internet-drafts directory by the working group and goes through all kinds of process and iteration before getting published as a proposed standard RFC. See eg https://en.wikipedia.org/wiki/Internet_Standard https://en.wikipedia.org/wiki/Internet_Standard

nikisweeting 6y ago

I'm surprised no one has linked to these two articles by @apenwarr yet, I consider them "the bible" for understanding IPv6 and why it was designed and implemented the way it was. - The world in which IPv6 was a good design: https://apenwarr.ca/log/20170810 https://apenwarr.ca/log/20170810 - IPv4, IPv6, and a sudden change in attitude: https://apenwarr.ca/log/20200708 https://apenwarr.ca/log/20200708

cblconfederate 6y ago

This is a great quick explainer for ipv6

pkulak 6y ago

Can't home routers, much like they all now have NTP by default, just have a firewall installed that by default blocks all incoming traffic unless it's a response to outgoing traffic? So, no prefix translation, everything has a real IP, and all incoming traffic still gets dropped on the floor by default.

fulafel 6y ago
Yes, that's how most CPEs work with ipv6 by default.

austincheney 6y ago

Whining. IPv6 is fantastic for two reasons: address space and no NAT. NAT, network address translation, means an artificial address space. That is all it means and it is limited by network size, even if that network is artificially addressed with nonrouteable addresses, which is small compared to PAT (port address translation). NAT is great if you want to hide from the world. It doesn't mean you have privacy. Everything can still leak out. It just means the outside cannot see you without a tunnel. In many way that actually hurts privacy because you cannot establish a point-to-point tunnel without a third party and that third party must have access to the transmission headers. NAT was never created for privacy or security. NAT and PAT were only created to extend the range of IPv4 addresses. In the web there is no point-to-point communication such as client-to-client. The web is only client-server. You make a request to the server, which establishes a tunnel and the server talks back with a response that follows the request in reverse. If you wanted to talk with a peer you would do so through a server. For example if you use iMessenger, Signal, or whatever you aren't directly talking to people. You are talking to a server and that server shares your messages with your friends. The server sees everything... no privacy. Even with end-to-end encryption you still relay everything through a server that knows half of every conversation. IPv6 does not have NAT. That is great. The security benefits of an artificial address space that isn't routed are still available in IPv6. This is from a range of addresses called link local that do not route. Since there is no NAT in IPv6 if you can see an outside computer that outside computer can see you equally. That means you don't need a server to chat with your friends. Just directly talk to your damn friends. No tunnel needed. End-to-end encryption can be as simple as HTTPS. You cannot get that with IPv4, largely due to NAT. Yes, only nerds care about privacy.... Well, no. If privacy is the default and end-to-end encryption is always the default you can do things and share things you would NEVER in a million years put on Facebook, because its actually private, like giving a USB hard drive directly to your life partner. That is a massive new set of business opportunities that scares the shit out of people on today's web (for good reason).

reanimus 6y ago

The complaints about allocating a percentage of IPv6 addresses for certain usages are a bit silly. Yeah, 1.271% of the addresses are private addresses. IPv6 has 340 trillion trillion trillion possible addresses. IPv4 has 4.2 billion.

ohgreatwtf 6y ago

we need a new standard for human design that emphasizes the simplicity and intuitive aspects. In all places. Laws, programming, etc. If it is too complex to readily use it and easily debug it, then it is bad. It is bad not because it is complex, but because it inserts overhead, and overhead in time spent solving problems is always exponential. I am for the idea of using ipv6 as a sort of nation-level NAT for big corporations and countries to expose part of a private address space over a section of ipv4, while each country gets most of ipv4 to itself along with a section where you can route to other countries, in exchange for a small fee. Say 30% of the ipv4 space is globally shared by everyone and the rest is local to your own country. Also IOT local mesh networks all would be on auto configured tunnels with only certain gateway systems hard coded- systems you can block at your router. That’s the most sensible solution. It will be a real shame if it is not the reality. Arrogance and “hurr durr i’m so smart and i spent 40 hours this week setting up this brilliant ipv6 network topology for my company that will require five manuals to fully explore and retain me in my job for a minimum of 10 years to keep it all working”- meanwhile the rest of us will suffer. The biggest most canally disgusting thing about ipv6 is that it will render dns based ad blocking a thing of the past. If you want any kind of blocking you will have to go with curated WHITELISTS, instead of blacklists. And that may be more secure but it will also be a lot more work, which, again, the ipv6 nerds will love to do but will present a hassle for the rest of us. You won’t be able to manually check the dns list anymore. you will simply have to accept that the overhead and the security risk of trusting all of the 35 million addresses in the whitelist is a cost you are willing to accept. Say no to ipv6. I have already blocked it on everything and will never adopt. it is the ethanol of internet addressing.

Dagger2 6y ago
You say you want simplicity, then you suggest a "nation-level NAT" that includes keeping v4 alive with overlapping allocations in multiple countries, NATing into v6 to talk to other countries, apparently for a fee that will need to be paid somehow. This is not simple, and is certainly not the most sensible solution. The simple and sensible solution is to just use v6. > The biggest most canally disgusting thing about ipv6 is that it will render dns based ad blocking a thing of the past. This claim is completely nonsensical. DNS-based ad blacklisting works just fine in v6. None of the problems you list with it exist. I suggest you unblock v6 and use it. You'll find it works the same as v4 does, just without the added complexity of NAT.

withinboredom 6y ago

Y’all are lucky. No ipv6 where I live. I’ve only gotten to play with it locally and occasionally on cloud servers. Don’t see the point in it.

Dagger2 6y ago
v4 isn't big enough to handle the current, let alone future, scale of the internet. The point of v6 is to be big enough to do that.

deleted 6y ago

[deleted]