20 ms·

IPv4 vs. IPv6 FAQ

216 points by mjs 5y ago

neilalexander 5y ago
> Why isn’t IPv6 more popular? ... and an arguably overly complex design. I really don't know where this ridiculous claim comes from. Yes, IPv6 addresses look more complicated but various other things about the protocol are drastically simplified — no more on-path fragmentation, simpler header formats and fewer required header fields, correctly implemented link-local scopes, previously separate ICMP+ARP+IGMP protocols consolidated into ICMPv6 (which handles neighbour discovery, router advertisements, path MTU discovery and multicast group membership amongst others), no more broadcast, and in many cases clients will quite happily get along without DHCP. If anything, it is considerably less complex.
- l0b0 5y ago
  There should be lots of implementations of both protocols by now - could we compare them for length and complexity to determine some sort of objective measure of the difference?
  - SSLy 5y ago
    Linux's net/ipv4 is 2.7MiB of code, net/ipv6 is 1.7MiB.
- pilif 5y ago
  While routing at global scale is much easier, running v6 in a local network has more moving parts than v4 had: - broadcasts for address discovery have been replaced by multicast which is much harder for switches to handle correctly - address discovery is now mostly handled via SLAAC which is different from how it worked via DHCP and also doesn't universally allow setting name servers which then will still require DHCP to actually get a working network (if you run v6 only), so now you have two daemons running when in v4 you only needed one. - hosts are multi-homed by default and rely heavily on multi-homedness which might invalidate some assumptions you had when configuring hosts. - for a network to be meaningfully useable, you need working name resolution because while you can remember v4 addresses and v4 address assignments, this is impossible for v6 addresses (yes, you can of course manually assign addresses in your prefix and you can just make them low numbers and hide everything else behind a ::, but you still have to remember your prefix which still is impossibly hard and there's no cheating there even if you know somebody at your ISP because it's not entirely under their control either) - and in a similar vein: Subnetting is harder because the addresses are much less memorable. If you want to subnet a 10.- v4 network, in many cases, you can do this in very memorable full-byte chunks. - also subnetting: due to many ISPs still doing /64 allocations to their customers, and due to the way how SLAAC works, you often have to decide between subnetting or SLAAC (which still is the default in many OSes). Worse, some ISPs only do a /128 assignment (one address), so now you're back in NAT territory, only that's really, really murky waters because next to nobody is doing this ATM. If your ISP only gives you a single v6 address, you are practically screwed about running v6 internally. If you're given a single v4 address (which is common practice), you can do NAT/RFC1918 addressing and you're fine. - v6 relies on ICMP much more heavily but this fact has not propagated to default firewall settings, so in many default "let me turn on the firewall" configs, your v6 network will break in mysterious ways. - in home networks where you want devices to be reachable directly (for P2P usages like video calls or gaming), there's no widely-supported equivalent to UPNP or NAT-PMP yet to punch holes into your firewall to make clients reachable. Yes, you don't have to do NAT any more, so clients are potentially reachable, but you really don't want that, so your firewall is still blocking all incoming connections, but now there's no way for an application to still punch temporary holes through which is a solved problem in v4 (where a hole is punched and a temporary port-mapping is created) There are more issues as your network grows bigger, but this is what I had to deal with in my small networks (<50 hosts) where I can say with certainty that v4 was much more straightforward to get up and running than v6 (though I was much older when I was learning v6 than when I was learning v4, so I might also just be getting old and slow) Yes. These are all solvable issues, but they are huge ergonomic downsides that are now pushed on local network admins to the point that for them it's still much easier to just disable ipv6 rather than learning about all these small issues and working around them. So while v6 is much easier to handle on a global scale, it's at the same time much harder to handle at your local site, but, the internet is as much about the global scale as it's about the local site and when the new thing is much harder to use than the old thing, inertia is even bigger than in the normal "everything is mostly the same" case (where inertia already feels like an insurmountable problem)
  - neilalexander 5y ago
    How switches "handle" multicast is not a new problem — many will treat it as broadcast traffic and flood it across the network segment, leaving clients to work out if they are interested or not. More intelligent switches might perform IGMP snooping to avoid flooding and this will be no more complex with IPv6 than it is with IPv4 today. Multihoming also isn't new and isn't really IPv6-specific. It might be more likely that you'll have multiple IPv6 prefixes but the majority of source address selection rules that you are used to in IPv4 will still apply, and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway. Subnetting is probably not easier or harder. The address length doesn't change how subnetting or how routing tables work and I am not really convinced that an IPv6 addressing plan should really be any worse or better than an IPv4 addressing plan. The minimum prefix size of /64 for a network segment is about the only extra consideration there, but if anything, it should be simpler than having to manage globally routable address space and private address space separately given that you can now manage address space as a true single hierarchy. You're right that SLAAC vs DHCP can add a bit of mental overhead, but for most configurations, configuring DHCP and letting RAs be sent automatically in IPv6 is not much different to configuring a default gateway in DHCP on an IPv4 network. Finally, as for ICMPv6, it has always been bad behaviour to just outright filter ICMP without consideration for what it will break. The stakes are indeed higher than in IPv4, but it seems worth it if we can eliminate two entirely separate protocols in the process and firewall vendors and admins are just going to have to learn that. I get there are a lot of cognitive factors involved in why people resist IPv6 but it really isn't as alien as most people think and most of the concerns are easily answered.
    - pilif 5y ago
      > many will treat it as broadcast traffic and flood it across the network segment and some will silently swallow them until you update their firmware. Broadcasts on the other hand are so common (and required for ipv4 to work) that they are rarely broken. If multicast is treated as broadcast, stuff works "fine", but because of IGMP snooping and additional "intelligence" the switches often employ, unfortunately, the failure modes I have seen tend to be packet loss rather than overeager packet forwarding. And with multicast packets dropped in a v4 network, some niche applications will stop working, but with multicasts packets dropped in a v6 network, your network will stop working. Period. > and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway of course you have. My point isn't that v6 multi-homing is any different from v4 multi-homing. My point is that multi-homing is rare with v4 but very common and required for v6. So what's often not an issue at all on anybodies radar in a v4 network is something everybody has to deal with in a v6 network. > most of the problems can be trivially solved. absolutely. But they don't have to be solved by staying with v4 and thus inertia is even harder to overcome than it normally is. That was my point.
- api 5y ago
  It’s less complex in many ways for machines but the long addresses make it unwieldy for human beings.
  - aaaaaaaaaaab 5y ago
    If only we could attach names to IP addresses somehow!
    - api 5y ago
      ... and have it work reliably ...? The real problem is standing up DNS on local or enclave networks with zero effort. Right now setting up DNS is a pain, configuring DNS is a pain, and mDNS doesn't scale and is slow.
  - e2le 5y ago
    At least in local network environments, using mdns (avahi) to discover other hosts is preferable and possibly more user friendly for less knowledgeable users.
- phicoh 5y ago
  In my experience, IPv6 is often more complex. The main exception is that by and large IPv6 doesn't have NAT, so that saves a few headaches in that area. No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems. Moving fragmentation to an extension header similarly creates problems. Dealing with extension headers is just more code complexity. Link local does not work (reliably) in browsers: https://[fe80::1]/ https://[fe80::1]/ doesn't work on most platforms. ICMP, ARP, and IGMP perform completely separate functions. Putting then all in ICMPv6 doesn't help. In contrast, having ND in ICMPv6 leads to code complexity. In IPv4, ICMP logically uses IP to send packets with uses ARP. In IPv6, ICMPv6 logically uses IPv6 to send packets, which uses ICMPv6 for neighbour discovery. IPv6 created a lot of flexibily by having multiple addresses per interface created automatically from router advertisements. And multiple routers on a subnet that can each support different prefixes (poor man's multihoming). Net result, certainly with devices that frequently connect to different networks, such as phones and laptops), is way too complex. That said, the only way forward is IPv6. Putting everything behind multiple layers of NAT is ultimately going to fail.
  - HALtheWise 5y ago
    I'm curious what you see as the reason that putting everything behind multiple layers of nat can't work? It seems to me like it has worked pretty well so far, and we're nowhere close to running out of (ip, port, ip, port) tuples.
    - zamadatix 5y ago
      1 layer of nat on each side hasn't bad, the 2 layers of nat on each side carriers have been moving to has been a godawful mess of complexity for any conversation where at least one side isnt a public IP (e.g. p2p chat/calls).
  - zamadatix 5y ago
    > No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems. I thought this was the other way around, IPv4 only guarantees reassembly up to 576 bytes so DNS avoided issues with split UDP datagrams by limiting the payload to 512. Ends stuff got added on once the defacto internet mtu became 1500 and there was more room. Things like 4G have a 1482 MTU though so it may seem frag!mentation helps but in reality most IPv4 routers don't fragment and reassemble anymore they just drop. In practice with DNS this has meant either keeping the packet size closer to 1k or using TCP which negotiates miss and handles correcting/merging lost split payloads. If anything IPv6 has made the situation cleaner with a minimum supported MTU of 1280 vs IPv4s 68 guaranteeing the 1kish UDP DNS payloads can make it through without relying on pmtud.
- crawshaw 5y ago
  Because it wasn't designed as a drop-in replacement, so using ipv6 necessarily means using ipv4+ipv6 for a time. That time is now twenty years and counting.
- benttoothpaste 5y ago
  I tried to set up IPv6 a while ago, and it looked simple at first. After configuring the router - just flipping "enable ipv6" in gui - my machine got 10 IPv6 addresses (why this many? I don't know). Cool. I then set up the firewall to expose one of these addresses and I could ssh to my machine from the outside world. A win! Unfortunately the win was short lived. Eventually I lost the ability to ssh in. It turned out that the 10 IPv6 addresses were replaced by a different bunch of 10 addresses. So I would have to reconfigure the firewall again. I decided it was too much work for me and disabled IPv6. Maybe some other time.
  - kaba0 5y ago
    How is that the fault of IPv6 over eg. your internet provider?
    - benttoothpaste 5y ago
      I did not blame anyone, just shared why it is not great for me.
  - BruiseLee 5y ago
    Believe it or not this feature is intentional. It is for your privacy so you cannot be tracked by your IP address...
  - jppittma 5y ago
    This is what dynamic dns is for. Your isp should have you covered there, and if not there are other free ones.
    - magicalhippo 5y ago
      How does dynamic DNS help change his firewall rules?
ryanschneider 5y ago
> At Tailscale we believe the main reason for the slow IPv6 rollout is that it simply has not been able to provide enough direct value, when deployed as a hybrid in parallel with IPv4. The intention was to deploy IPv6, then retire IPv4 completely, in which case IPv6 would have made the Internet overall simpler and cheaper to manage, which is a big benefit. Unfortunately, this value doesn’t materialize until the very end, after IPv6 has been fully deployed to billions of devices. This means companies usually will not recoup the costs of IPv6 deployment on a predictable timeline, which makes investment hard. Anyone else get a strong climate change parallel vibe from this section? Hopefully the stronger (dis)incentives of a slower rollout of carbon reduction efforts will be able to overcome some of these same obstacles.
Thiez 5y ago
> IPv6 has several advantages, including a much larger address space. IPv4 had only 2^32 addresses, less than one per person on earth. IPv6 has 2^128 addresses, an immensely larger number which is not expected ever to be exhausted. Estimates are that this is enough to assign 100 IPv6 addresses to every atom on earth. Yeah, so that's overestimating the number of IPv6 addresses by quite a couple of orders of magnitude. This website estimates the number of atoms at 10^49 to 10^50, whereas 2^128 is in the order of 3 * 10^38. https://www.fnal.gov/pub/science/inquiring/questions/atoms.html https://www.fnal.gov/pub/science/inquiring/questions/atoms.h... Perhaps the writer was thinking of grains of sand instead of atoms? I'm not sure how many sand we have, but it's probably more in the 2^128 ballpark.
- deleted 5y ago
  [deleted]
- throw0101a 5y ago
  Another way of thinking about it: * Stars in the Milky Way: 400 Billion * Galaxes in the universe: 2 Trillion So (4x10^11)x(2x10^12)=8x10^23 stars in the universe. * Size of IPv6 address space: 3.4x10^38 Find the ratio between addresses and stars: * 3.4x10^38 / 8x10^23 IPv6 offers about 430 trillion times more addresses than estimated stars in the universe. From Tom Coffee's presentation "An Enterprise IPv6 Address Planning Case-Study" * https://www.youtube.com/watch?v=7Tnh4upTOC4 https://www.youtube.com/watch?v=7Tnh4upTOC4
  - deleted 5y ago
    [deleted]
  - JuettnerDistrib 5y ago
    Perhaps in more human terms: On the surface of the Earth, there are 8.4 IPv4 addresses per km^2. Not counting the oceans, that would be 28 IPv4 addresses per km^2 land. IPv6 gives 10^17 addresses per mm^2 (yes, square millimeter). In terms of volume, 10^8 IPv6 addresses per mm^3 throughout the Earth.
    - 5y ago
everdrive 5y ago
>The primary purpose of IPv6 was to expand the address space of IPv4. I wish this were all it did. People can make arguments about IPv6 being "simpler," but it's often not simpler in practice: - You still need to run dual-stack - You need to re-learn a lot of your networking fundamentals - Despite IPv6 being effectively infinite, most ISPs will not give you a static IP - Most hardware is built for IPv4 and NOT IPv6 - Local subnetting is far more complicated. Not just due to the the length of the address, but due to the fact that you often need to work out SLAAC and/or have a local DNS service to handle the address changes.
- drewg123 5y ago
  I think that if they just would have increased the size of IP addresses from 32- to 64-bits, the conversion would have been completed 15 years ago.
  - p_l 5y ago
    Around 1990~1991, the TUBA proposal was already ready to go with two implementations (one on hardware router), bringing addresses to iirc either 160bits or 144 bits (don't recall exactly, been long time). Might have been better if they went for 144 bit host name and embedded port numbers in the last 2 bytes, but the point was to run TCP and UDP close to unchanged. Then IPng got started and for most of 1990s IETF played with sweeping changes while "temporary solution" that was IPv4 entrenched itself in worse and worse ways.
    - drewg123 5y ago
      I was an undergrad then, and wasn't really aware of this sort of thing. I just went and read the TUBA RFC (rfc1347), and it looks like CNLP was no walk in the part either. From the RFC: CLNP contains a number of optional and/or variable length fields. For example, CLNP allows addresses to be any integral number of bytes up to 20 bytes in length Did anybody advocate for the simple approach of just expanding the in_addr from 32 to 64 bits, calling it IPv5 and being done with it? That's what I think would have been the right thing to do..
devwastaken 5y ago
ISP's and networks love clients being behind NAT, so they can't directly host to the outside world and can't rely on a static address. Ipv4 is a scarce resource, therefore it's valuable. Various people don't want that to go away. The only way we're going to get ipv6 everywhere is when the feds start requiring it. The internet being a world resource should be of significant concern to every country. The limited number of ipv4 resources is a weakness of the U.S. and othe western countries. As is the lack of "cyber security".
- est31 5y ago
  Note that IPv6 doesn't necessarily have static addresses either. Also note that IPv6 support on the client side is gradually increasing. With current trends we'll reach the 100% in the next decade. At a certain point, some services will go IPv6 only.
  - devwastaken 5y ago
    Yes, but it makes static addressing far more affordable, and justifiable. Especially in city board meetings where an issue like that is raised. Ipv6 is effectively supported everywhere but the ISP. Again, it's intentional, the only reason they'll change is federal requirements. It's the only reason the ISP here does 25/4. Because broadband requirements. They didn't change anything to do it either, they just flipped the switch. Costed them maybe a couple thousand in labor.
- qwertox 5y ago
  > Ipv4 is a scarce resource, therefore it's valuable. I don't know how valid this argument is in this context. Most ISP clients nowadays are connected 24/7, so they are using an IPv4 anyway. They might as well keep the same IP over a larger period of time. Vodafone Cable and Telekom VDSL, both in Germany, only change your IP if they have to. You'll usually have the same one for many months. Also, the NAT you're referring to is the one which runs on the customer's hardware, and usually the customer has the option to set up port forwarding. All this is in the IPv4 / Dual Stack context.
  - 5y ago
strenholme 5y ago
My issue with IPv6 is that its designers assume that everyone with an IPv6 network will get static IPv6 addresses. However, it didn’t turn out that way in the real world. Every time my router resets, all of the IPv6 addresses in my home network change. So, I don’t use IPv6 to connect among computers in my home network; since I also get one IPv4 address from my ISP, I simply use IPv4 NAT so that the addresses in my home network are easily remembered and do not change. The reason I don’t use IPv6 and 6:6 NAT is because the IPv6 designers feel this makes networking too complicated, never mind that NAT is a solved problem, so 6:6 NAT support just really isn’t there. Another annoyance I have with IPv6 is that it needs to have more than one localhost IP address, considering that IPv4 has a 24-bit space for localhost. A large number of localhost addresses is useful for network regression tests (e.g. if we have one authoritative DNS server on 127.10.0.1 and one which isn’t responding on 127.10.0.2, does our recursive DNS server on 127.12.0.1 correctly handle an upstream DNS server being down? Nice to be able to run the test using only localhost IPs; also nice to be able to change the IPs each test so we don’t have to wait for the kernel to release TCP sockets for a given IP + port). For the record, I have gone to a lot of effort to give my open source networking software IPv6 support.
- goalieca 5y ago
  You’ll get a few ipv6 address two of which may be local (link-local and routable unique local). The global one will be randomized too within your block for privacy. Now with that in mind, the implementations do all kinds of funny things that don’t seem to meet spec when it comes to router advertisement (the dhcp replacement) and routing. Use the wrong kind of address for the gateway and nothing works for instance.
- est31 5y ago
  > So, I don’t use IPv6 to connect among computers in my home network; since I also get one IPv4 address from my ISP, I simply use IPv4 NAT so that the addresses in my home network are easily remembered and do not change. Why do you need NAT at all? You can just use IPv4 to communicate among hosts in the network, and use IPv6 for them to communicate with the world. Nothing about IPv6 forbids the existence of IPv4.
mtekman 5y ago
For anyone wondering why they cant access their ipv6-addressed pi box from public WiFi networks: those public networks still use ipv4 and assign you only a lonk-local ipv6 address. To go from 4 to 6, the public WiFi box will need to use a 4 to 6 "broker" and there are surprisingly few of these around and they're not usually free. So basically, your home network and Pi is future-ready, but public infrastructure might need a moment...
technologesus 5y ago
To me the most important thing about IPv6 is how it enables reliable peer to peer networks. IPv4 is the bane of existence to p2p networks since you have to so much extra shit to make it work (Public address discovery, NAT hole punching, relaying connections through some machine with an open port). With IPv6 you can just stick your address on a DHT and peers can connect to you 100% of the time, no matter what. The only thing that sucks is that you can't count on an internet-connceted device having IPv6 yet.
- tsimionescu 5y ago
  > With IPv6 you can just stick your address on a DHT and peers can connect to you 100% of the time, no matter what. How do you keep that secure, so that you don't get spammed by any bot on the internet?
  - kazen44 5y ago
    a firewall
    - tsimionescu 5y ago
      Peers connect to you by opening a connection to the advertised IP(s) and port. Bots connect to you by opening a connection to the advertised IP(s) and port. How do you tell which is which? With hole punching, at least you have some amount of mutual recognition by using the same external server, and you get some amount of DoS protection from the server itself (though of course the server will likely support many more connections than your local system). So in the end, aren't you more secure using a hole punch method for direct connections over the internet for P2P communication, even on IPv6?
      - growse 5y ago
        > So in the end, aren't you more secure using a hole punch method for direct connections over the internet for P2P communication, even on IPv6? No? It sounds like you're reinventing authentication, badly. If you want to control which clients are permitted to access a service available, we have well-established ways of doing that. Dynamically messing around with the network and "hole-punching" is not one of them (unless you broaden that to mean VPNs, but if you want a VPN, use a VPN!). If you don't want anyone on the internet to be able to SYN/ACK to a TCP service you put on the internet, don't put it on the internet. Also, insert standard soapbox speech here about how the contextless phrase "more secure" is meaningless. More secure against what? What's the threat or risk you're trying to control?
ignoramous 5y ago
> What would a backward-compatible address extension to IPv4 look like? See also: https://en.wikipedia.org/wiki/IPv6_transition_mechanism https://en.wikipedia.org/wiki/IPv6_transition_mechanism
willis936 5y ago
>Empirically, some ISPs route IPv4 more efficiently and some route IPv6 more efficiently. It is so refreshing to see this written down somewhere. All of the academic papers I've seen comparing the empirical routing performance between IPv4 and IPv6 show a negligible performance difference. However, in the two states I've lived where I have looked at IPv6 vs IPv4 performance I see consistently higher pings with IPv6. Traceroute reveals that each individual hop adds the about the same amount of latency, but there are ~15% more hops for IPv6. If I play a competitive game then I don't want to be adding 10 ms of latency unnecessarily. So I just disable IPv6 on my gaming rig? C'mon. We can do better.
- rkeene2 5y ago
  You can thank large backbone providers for this. IPv6 works just fine over the same L2 link as IPv4, so there would never need to be any more hops than IPv4 (sometimes they do need to upgrade equipment to support IPv6 so they may be DIFFERENT hops over DIFFERENT L2 links, but they could also move their IPv4 traffic to that new equipment). What happens is when the large backbone providers have disputes, the de-peer with each other IPv6, which causes rerouting to be visible. They can't "punish" the other with IPv4 depeering, since that would make their own customers angry.
cube00 5y ago
> Should I support IPv6 on my server? > You can if you want, but despite what some people will claim, it probably won’t make much difference. This apathy is exactly why adoption is slow. For all its faults Google needs to be commended for their commitment to IPv6. They are the only large email provider I see sending and receiving email using IPv6 even though "it probably won’t make much difference"
- p_l 5y ago
  It also helps when you connect from mobile networks, as due to various things (including, afaik, licensing shenanigans) there's a huge push for v6 in mobile networking. Even your v4 traffic is probably going over v6 using 4x6x4 translation.
- willis936 5y ago
  It's okay imo. IPv4 on the internet is getting very expensive very fast. The market will do its thing and the solution is already on hand: IPv6. The addresses are virtually free. Sure it's not with all the fanfare and it doesn't meet all of its promises, but it will happen and fast.
  - loup-vaillant 5y ago
    Close to 5€ per month for my virtual server. Almost half the total cost. I’m still paying them because I’m not sure people could still contact my web server (and when I used it my mail server) if it was IPv6 only.
- zinekeller 5y ago
  Mr. cube00, for a static website it's a toss-up (you should activate it anyway if you're able to!). The problem is that (for example) for forums etc., 40-bit addresses (the best-approximation considering that only a slice was allocated and /64 is treated as a single network connection) adds a whole lot of problems when it comes to combating spam etc. 8 bits sounds like nothing to you but you multiplied their problem 256 times. In shorter words, it's not always economical to turn the proverbial switch on. For Google, they can rely on their AIs but for small forums? That's just (unfortunately) an additional attack surface on something that they want to be gone.
anonymousiam 5y ago
I've been playing with IPv6 for over a decade. My observations are that it's actually faster across the backbone. I'm not sure why this is. A very useful site: https://ipv6-test.com/ https://ipv6-test.com/
bombcar 5y ago
Let’s get 128 bits but give everyone a /48 and so have only 16 bits more effectively wooohooo Shoulda gone for 1024 bits and made people really whine
- rkeene2 5y ago
  Keep in mind this allocation strategy only affects 1/8th of all IPv6 space, so if we picked the wrong one we have the other 7/8ths to use in a (hopefully) better strategy.
lowercased 5y ago
I'm curious when we'll declare some sort of "idea bankruptcy" on IPv6, develop a new version (IPv7?) that has a "ease of migration from IPv4" as a stated goal, and deploy/implement that. Knowing the historical transition issues collected over the past 20 years, we could, as an industry and society, design a next generation and provide a reasonable rollout target of, say, 2030, and move towards that. Since 1998/99, there's been an explosion of networking, and large cultural shifts (billions of mobile devices, IoT, etc) which were not around when all this was specced out. No technology adopted IPv6 as a default during that time, and I dare say most things (services, devices, etc) aren't even tested against IPv6. After 20+ years of this, I see IPv6 as a failure, even if there is 30-50% adoption (or perhaps because of those figures).
- jl6 5y ago
  With ~30% adoption of IPv6 today, your great new alternative is going to need an “ease of migration from IPv6” feature too.
  - zinekeller 5y ago
    Nope, you don't need to, because of a simple fact that there is a very minuscule amount of IPv6-reliant systems in the wild. Most of them also operate in IPv4 (because IPv4 is more prevalent). Name me an existing system where: a) requires IPv6; but b) not because of its long address. Good luck finding such a system.
    - kazen44 5y ago
      mobile telecom gateways? most modern telecom uses ipv6 for LTE communication, with nat64 to communicate with ipv4.
  - formerly_proven 5y ago
    Not really, since IPv6 adoption is low, a service that doesn't also exist on IPv4 practically does not exist, so if you have a good migration path (unlike v6) from v4, you're taking approximately all services with you.
zinekeller 5y ago
Sidenote to all of this, an IPv4-compatible upgrade path in 1992: https://datatracker.ietf.org/doc/html/rfc1347 https://datatracker.ietf.org/doc/html/rfc1347
- Dagger2 5y ago
  Can you explain how it was compatible? That RFC says "Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged." which sounds exactly the same as the way v6 normally does it. As far as I could tell from the RFC, if TUBA counts as v4-compatible then so does v6.
- throw0101a 5y ago
  This was brought up in another part of the thread. I'm copy-pasting my reply: --- From the RFC (emphasis added): > The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses. […] In §3 Migration: > Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup. So you're replacing IPv4 with something that is not-IPv4 on every router and every host. During the transition period everyone will have IPv4 and not-IPv4 addresses. How is not-IPv4 being CLNP/NSAP any different that not-IPv4 being IPv6? What am I missing? In §6 on DNS: > TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses. Which is basically describing AAAA records. --- * https://news.ycombinator.com/item?id=28326806#unv_28328593 https://news.ycombinator.com/item?id=28326806#unv_28328593
rswail 5y ago
Well it appears that routing to google from home is pretty much the same: ping google.com round-trip min/avg/max/stddev = 5.925/7.695/10.634/2.093 ms ping6 google.com round-trip min/avg/max/std-dev = 6.348/8.013/10.869/1.965 ms traceroute and traceroute6 both had 8 hops.
GenaroHR 5y ago
As someone who experience many problems with Multicast on IPv4 / IPv6 hybrid networks, how different are the implementation of Broadcasting on each protocol? Mostly I came aware that in IPV4 the router tries to create a local multicast group, using IGMP snooping you can solve some problems to get your broadcast thru multiple devices, but in IPv6 this is kind of confusing to me... does any one has information on this?
sophacles 5y ago
I firmly believe IPv6 adoption is hindered by one little reason more than any other: i can't easily remember an ipv6 address. Its too big, its in hex, and that adds friction to everything. With v4 i can just look at an ip, remember it for a second and type it into whatever config/program/etc i need. I can tell a colleague across the room "that ip is:...". I know there's the condensed address format, but that just makes communicating it harder. Typo `::` as `:`? Now you have a problem that's not easy to see. Its a small friction, but it adds up quickly and makes working with ipv6 feel sluggish and painful. (A common response when i say this is "isn't that what DNS is for?" and yes, it is. That's great once you have DNS and reverse DNS working, but "its always dns" is a meme for a reason).
throw7 5y ago
I'm on linux... Is there some document on how I can tell if i'm getting ipv6, a description of what i'm seeing or what to expect, and what I can do with it that is cool?

216 points by mjs 5y ago

> Why isn’t IPv6 more popular? ... and an arguably overly complex design. I really don't know where this ridiculous claim comes from. Yes, IPv6 addresses look more complicated but various other things about the protocol are drastically simplified — no more on-path fragmentation, simpler header formats and fewer required header fields, correctly implemented link-local scopes, previously separate ICMP+ARP+IGMP protocols consolidated into ICMPv6 (which handles neighbour discovery, router advertisements, path MTU discovery and multicast group membership amongst others), no more broadcast, and in many cases clients will quite happily get along without DHCP. If anything, it is considerably less complex.

l0b0 5y ago
There should be lots of implementations of both protocols by now - could we compare them for length and complexity to determine some sort of objective measure of the difference?
- SSLy 5y ago
  Linux's net/ipv4 is 2.7MiB of code, net/ipv6 is 1.7MiB.
pilif 5y ago
While routing at global scale is much easier, running v6 in a local network has more moving parts than v4 had: - broadcasts for address discovery have been replaced by multicast which is much harder for switches to handle correctly - address discovery is now mostly handled via SLAAC which is different from how it worked via DHCP and also doesn't universally allow setting name servers which then will still require DHCP to actually get a working network (if you run v6 only), so now you have two daemons running when in v4 you only needed one. - hosts are multi-homed by default and rely heavily on multi-homedness which might invalidate some assumptions you had when configuring hosts. - for a network to be meaningfully useable, you need working name resolution because while you can remember v4 addresses and v4 address assignments, this is impossible for v6 addresses (yes, you can of course manually assign addresses in your prefix and you can just make them low numbers and hide everything else behind a ::, but you still have to remember your prefix which still is impossibly hard and there's no cheating there even if you know somebody at your ISP because it's not entirely under their control either) - and in a similar vein: Subnetting is harder because the addresses are much less memorable. If you want to subnet a 10.- v4 network, in many cases, you can do this in very memorable full-byte chunks. - also subnetting: due to many ISPs still doing /64 allocations to their customers, and due to the way how SLAAC works, you often have to decide between subnetting or SLAAC (which still is the default in many OSes). Worse, some ISPs only do a /128 assignment (one address), so now you're back in NAT territory, only that's really, really murky waters because next to nobody is doing this ATM. If your ISP only gives you a single v6 address, you are practically screwed about running v6 internally. If you're given a single v4 address (which is common practice), you can do NAT/RFC1918 addressing and you're fine. - v6 relies on ICMP much more heavily but this fact has not propagated to default firewall settings, so in many default "let me turn on the firewall" configs, your v6 network will break in mysterious ways. - in home networks where you want devices to be reachable directly (for P2P usages like video calls or gaming), there's no widely-supported equivalent to UPNP or NAT-PMP yet to punch holes into your firewall to make clients reachable. Yes, you don't have to do NAT any more, so clients are potentially reachable, but you really don't want that, so your firewall is still blocking all incoming connections, but now there's no way for an application to still punch temporary holes through which is a solved problem in v4 (where a hole is punched and a temporary port-mapping is created) There are more issues as your network grows bigger, but this is what I had to deal with in my small networks (<50 hosts) where I can say with certainty that v4 was much more straightforward to get up and running than v6 (though I was much older when I was learning v6 than when I was learning v4, so I might also just be getting old and slow) Yes. These are all solvable issues, but they are huge ergonomic downsides that are now pushed on local network admins to the point that for them it's still much easier to just disable ipv6 rather than learning about all these small issues and working around them. So while v6 is much easier to handle on a global scale, it's at the same time much harder to handle at your local site, but, the internet is as much about the global scale as it's about the local site and when the new thing is much harder to use than the old thing, inertia is even bigger than in the normal "everything is mostly the same" case (where inertia already feels like an insurmountable problem)
- neilalexander 5y ago
  How switches "handle" multicast is not a new problem — many will treat it as broadcast traffic and flood it across the network segment, leaving clients to work out if they are interested or not. More intelligent switches might perform IGMP snooping to avoid flooding and this will be no more complex with IPv6 than it is with IPv4 today. Multihoming also isn't new and isn't really IPv6-specific. It might be more likely that you'll have multiple IPv6 prefixes but the majority of source address selection rules that you are used to in IPv4 will still apply, and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway. Subnetting is probably not easier or harder. The address length doesn't change how subnetting or how routing tables work and I am not really convinced that an IPv6 addressing plan should really be any worse or better than an IPv4 addressing plan. The minimum prefix size of /64 for a network segment is about the only extra consideration there, but if anything, it should be simpler than having to manage globally routable address space and private address space separately given that you can now manage address space as a true single hierarchy. You're right that SLAAC vs DHCP can add a bit of mental overhead, but for most configurations, configuring DHCP and letting RAs be sent automatically in IPv6 is not much different to configuring a default gateway in DHCP on an IPv4 network. Finally, as for ICMPv6, it has always been bad behaviour to just outright filter ICMP without consideration for what it will break. The stakes are indeed higher than in IPv4, but it seems worth it if we can eliminate two entirely separate protocols in the process and firewall vendors and admins are just going to have to learn that. I get there are a lot of cognitive factors involved in why people resist IPv6 but it really isn't as alien as most people think and most of the concerns are easily answered.
  - pilif 5y ago
    > many will treat it as broadcast traffic and flood it across the network segment and some will silently swallow them until you update their firmware. Broadcasts on the other hand are so common (and required for ipv4 to work) that they are rarely broken. If multicast is treated as broadcast, stuff works "fine", but because of IGMP snooping and additional "intelligence" the switches often employ, unfortunately, the failure modes I have seen tend to be packet loss rather than overeager packet forwarding. And with multicast packets dropped in a v4 network, some niche applications will stop working, but with multicasts packets dropped in a v6 network, your network will stop working. Period. > and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway of course you have. My point isn't that v6 multi-homing is any different from v4 multi-homing. My point is that multi-homing is rare with v4 but very common and required for v6. So what's often not an issue at all on anybodies radar in a v4 network is something everybody has to deal with in a v6 network. > most of the problems can be trivially solved. absolutely. But they don't have to be solved by staying with v4 and thus inertia is even harder to overcome than it normally is. That was my point.
api 5y ago
It’s less complex in many ways for machines but the long addresses make it unwieldy for human beings.
- aaaaaaaaaaab 5y ago
  If only we could attach names to IP addresses somehow!
  - api 5y ago
    ... and have it work reliably ...? The real problem is standing up DNS on local or enclave networks with zero effort. Right now setting up DNS is a pain, configuring DNS is a pain, and mDNS doesn't scale and is slow.
- e2le 5y ago
  At least in local network environments, using mdns (avahi) to discover other hosts is preferable and possibly more user friendly for less knowledgeable users.
phicoh 5y ago
In my experience, IPv6 is often more complex. The main exception is that by and large IPv6 doesn't have NAT, so that saves a few headaches in that area. No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems. Moving fragmentation to an extension header similarly creates problems. Dealing with extension headers is just more code complexity. Link local does not work (reliably) in browsers: https://[fe80::1]/ https://[fe80::1]/ doesn't work on most platforms. ICMP, ARP, and IGMP perform completely separate functions. Putting then all in ICMPv6 doesn't help. In contrast, having ND in ICMPv6 leads to code complexity. In IPv4, ICMP logically uses IP to send packets with uses ARP. In IPv6, ICMPv6 logically uses IPv6 to send packets, which uses ICMPv6 for neighbour discovery. IPv6 created a lot of flexibily by having multiple addresses per interface created automatically from router advertisements. And multiple routers on a subnet that can each support different prefixes (poor man's multihoming). Net result, certainly with devices that frequently connect to different networks, such as phones and laptops), is way too complex. That said, the only way forward is IPv6. Putting everything behind multiple layers of NAT is ultimately going to fail.
- HALtheWise 5y ago
  I'm curious what you see as the reason that putting everything behind multiple layers of nat can't work? It seems to me like it has worked pretty well so far, and we're nowhere close to running out of (ip, port, ip, port) tuples.
  - zamadatix 5y ago
    1 layer of nat on each side hasn't bad, the 2 layers of nat on each side carriers have been moving to has been a godawful mess of complexity for any conversation where at least one side isnt a public IP (e.g. p2p chat/calls).
- zamadatix 5y ago
  > No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems. I thought this was the other way around, IPv4 only guarantees reassembly up to 576 bytes so DNS avoided issues with split UDP datagrams by limiting the payload to 512. Ends stuff got added on once the defacto internet mtu became 1500 and there was more room. Things like 4G have a 1482 MTU though so it may seem frag!mentation helps but in reality most IPv4 routers don't fragment and reassemble anymore they just drop. In practice with DNS this has meant either keeping the packet size closer to 1k or using TCP which negotiates miss and handles correcting/merging lost split payloads. If anything IPv6 has made the situation cleaner with a minimum supported MTU of 1280 vs IPv4s 68 guaranteeing the 1kish UDP DNS payloads can make it through without relying on pmtud.
crawshaw 5y ago
Because it wasn't designed as a drop-in replacement, so using ipv6 necessarily means using ipv4+ipv6 for a time. That time is now twenty years and counting.
benttoothpaste 5y ago
I tried to set up IPv6 a while ago, and it looked simple at first. After configuring the router - just flipping "enable ipv6" in gui - my machine got 10 IPv6 addresses (why this many? I don't know). Cool. I then set up the firewall to expose one of these addresses and I could ssh to my machine from the outside world. A win! Unfortunately the win was short lived. Eventually I lost the ability to ssh in. It turned out that the 10 IPv6 addresses were replaced by a different bunch of 10 addresses. So I would have to reconfigure the firewall again. I decided it was too much work for me and disabled IPv6. Maybe some other time.
- kaba0 5y ago
  How is that the fault of IPv6 over eg. your internet provider?
  - benttoothpaste 5y ago
    I did not blame anyone, just shared why it is not great for me.
- BruiseLee 5y ago
  Believe it or not this feature is intentional. It is for your privacy so you cannot be tracked by your IP address...
- jppittma 5y ago
  This is what dynamic dns is for. Your isp should have you covered there, and if not there are other free ones.
  - magicalhippo 5y ago
    How does dynamic DNS help change his firewall rules?

ryanschneider 5y ago

> At Tailscale we believe the main reason for the slow IPv6 rollout is that it simply has not been able to provide enough direct value, when deployed as a hybrid in parallel with IPv4. The intention was to deploy IPv6, then retire IPv4 completely, in which case IPv6 would have made the Internet overall simpler and cheaper to manage, which is a big benefit. Unfortunately, this value doesn’t materialize until the very end, after IPv6 has been fully deployed to billions of devices. This means companies usually will not recoup the costs of IPv6 deployment on a predictable timeline, which makes investment hard. Anyone else get a strong climate change parallel vibe from this section? Hopefully the stronger (dis)incentives of a slower rollout of carbon reduction efforts will be able to overcome some of these same obstacles.

Thiez 5y ago

> IPv6 has several advantages, including a much larger address space. IPv4 had only 2^32 addresses, less than one per person on earth. IPv6 has 2^128 addresses, an immensely larger number which is not expected ever to be exhausted. Estimates are that this is enough to assign 100 IPv6 addresses to every atom on earth. Yeah, so that's overestimating the number of IPv6 addresses by quite a couple of orders of magnitude. This website estimates the number of atoms at 10^49 to 10^50, whereas 2^128 is in the order of 3 * 10^38. https://www.fnal.gov/pub/science/inquiring/questions/atoms.html https://www.fnal.gov/pub/science/inquiring/questions/atoms.h... Perhaps the writer was thinking of grains of sand instead of atoms? I'm not sure how many sand we have, but it's probably more in the 2^128 ballpark.

deleted 5y ago
[deleted]
throw0101a 5y ago
Another way of thinking about it: * Stars in the Milky Way: 400 Billion * Galaxes in the universe: 2 Trillion So (4x10^11)x(2x10^12)=8x10^23 stars in the universe. * Size of IPv6 address space: 3.4x10^38 Find the ratio between addresses and stars: * 3.4x10^38 / 8x10^23 IPv6 offers about 430 trillion times more addresses than estimated stars in the universe. From Tom Coffee's presentation "An Enterprise IPv6 Address Planning Case-Study" * https://www.youtube.com/watch?v=7Tnh4upTOC4 https://www.youtube.com/watch?v=7Tnh4upTOC4
- deleted 5y ago
  [deleted]
- JuettnerDistrib 5y ago
  Perhaps in more human terms: On the surface of the Earth, there are 8.4 IPv4 addresses per km^2. Not counting the oceans, that would be 28 IPv4 addresses per km^2 land. IPv6 gives 10^17 addresses per mm^2 (yes, square millimeter). In terms of volume, 10^8 IPv6 addresses per mm^3 throughout the Earth.
  - 5y ago

everdrive 5y ago

>The primary purpose of IPv6 was to expand the address space of IPv4. I wish this were all it did. People can make arguments about IPv6 being "simpler," but it's often not simpler in practice: - You still need to run dual-stack - You need to re-learn a lot of your networking fundamentals - Despite IPv6 being effectively infinite, most ISPs will not give you a static IP - Most hardware is built for IPv4 and NOT IPv6 - Local subnetting is far more complicated. Not just due to the the length of the address, but due to the fact that you often need to work out SLAAC and/or have a local DNS service to handle the address changes.

drewg123 5y ago
I think that if they just would have increased the size of IP addresses from 32- to 64-bits, the conversion would have been completed 15 years ago.
- p_l 5y ago
  Around 1990~1991, the TUBA proposal was already ready to go with two implementations (one on hardware router), bringing addresses to iirc either 160bits or 144 bits (don't recall exactly, been long time). Might have been better if they went for 144 bit host name and embedded port numbers in the last 2 bytes, but the point was to run TCP and UDP close to unchanged. Then IPng got started and for most of 1990s IETF played with sweeping changes while "temporary solution" that was IPv4 entrenched itself in worse and worse ways.
  - drewg123 5y ago
    I was an undergrad then, and wasn't really aware of this sort of thing. I just went and read the TUBA RFC (rfc1347), and it looks like CNLP was no walk in the part either. From the RFC: CLNP contains a number of optional and/or variable length fields. For example, CLNP allows addresses to be any integral number of bytes up to 20 bytes in length Did anybody advocate for the simple approach of just expanding the in_addr from 32 to 64 bits, calling it IPv5 and being done with it? That's what I think would have been the right thing to do..

devwastaken 5y ago

ISP's and networks love clients being behind NAT, so they can't directly host to the outside world and can't rely on a static address. Ipv4 is a scarce resource, therefore it's valuable. Various people don't want that to go away. The only way we're going to get ipv6 everywhere is when the feds start requiring it. The internet being a world resource should be of significant concern to every country. The limited number of ipv4 resources is a weakness of the U.S. and othe western countries. As is the lack of "cyber security".

est31 5y ago
Note that IPv6 doesn't necessarily have static addresses either. Also note that IPv6 support on the client side is gradually increasing. With current trends we'll reach the 100% in the next decade. At a certain point, some services will go IPv6 only.
- devwastaken 5y ago
  Yes, but it makes static addressing far more affordable, and justifiable. Especially in city board meetings where an issue like that is raised. Ipv6 is effectively supported everywhere but the ISP. Again, it's intentional, the only reason they'll change is federal requirements. It's the only reason the ISP here does 25/4. Because broadband requirements. They didn't change anything to do it either, they just flipped the switch. Costed them maybe a couple thousand in labor.
qwertox 5y ago
> Ipv4 is a scarce resource, therefore it's valuable. I don't know how valid this argument is in this context. Most ISP clients nowadays are connected 24/7, so they are using an IPv4 anyway. They might as well keep the same IP over a larger period of time. Vodafone Cable and Telekom VDSL, both in Germany, only change your IP if they have to. You'll usually have the same one for many months. Also, the NAT you're referring to is the one which runs on the customer's hardware, and usually the customer has the option to set up port forwarding. All this is in the IPv4 / Dual Stack context.
- 5y ago

strenholme 5y ago

My issue with IPv6 is that its designers assume that everyone with an IPv6 network will get static IPv6 addresses. However, it didn’t turn out that way in the real world. Every time my router resets, all of the IPv6 addresses in my home network change. So, I don’t use IPv6 to connect among computers in my home network; since I also get one IPv4 address from my ISP, I simply use IPv4 NAT so that the addresses in my home network are easily remembered and do not change. The reason I don’t use IPv6 and 6:6 NAT is because the IPv6 designers feel this makes networking too complicated, never mind that NAT is a solved problem, so 6:6 NAT support just really isn’t there. Another annoyance I have with IPv6 is that it needs to have more than one localhost IP address, considering that IPv4 has a 24-bit space for localhost. A large number of localhost addresses is useful for network regression tests (e.g. if we have one authoritative DNS server on 127.10.0.1 and one which isn’t responding on 127.10.0.2, does our recursive DNS server on 127.12.0.1 correctly handle an upstream DNS server being down? Nice to be able to run the test using only localhost IPs; also nice to be able to change the IPs each test so we don’t have to wait for the kernel to release TCP sockets for a given IP + port). For the record, I have gone to a lot of effort to give my open source networking software IPv6 support.

goalieca 5y ago
You’ll get a few ipv6 address two of which may be local (link-local and routable unique local). The global one will be randomized too within your block for privacy. Now with that in mind, the implementations do all kinds of funny things that don’t seem to meet spec when it comes to router advertisement (the dhcp replacement) and routing. Use the wrong kind of address for the gateway and nothing works for instance.
est31 5y ago
> So, I don’t use IPv6 to connect among computers in my home network; since I also get one IPv4 address from my ISP, I simply use IPv4 NAT so that the addresses in my home network are easily remembered and do not change. Why do you need NAT at all? You can just use IPv4 to communicate among hosts in the network, and use IPv6 for them to communicate with the world. Nothing about IPv6 forbids the existence of IPv4.

mtekman 5y ago

For anyone wondering why they cant access their ipv6-addressed pi box from public WiFi networks: those public networks still use ipv4 and assign you only a lonk-local ipv6 address. To go from 4 to 6, the public WiFi box will need to use a 4 to 6 "broker" and there are surprisingly few of these around and they're not usually free. So basically, your home network and Pi is future-ready, but public infrastructure might need a moment...

technologesus 5y ago

To me the most important thing about IPv6 is how it enables reliable peer to peer networks. IPv4 is the bane of existence to p2p networks since you have to so much extra shit to make it work (Public address discovery, NAT hole punching, relaying connections through some machine with an open port). With IPv6 you can just stick your address on a DHT and peers can connect to you 100% of the time, no matter what. The only thing that sucks is that you can't count on an internet-connceted device having IPv6 yet.

tsimionescu 5y ago
> With IPv6 you can just stick your address on a DHT and peers can connect to you 100% of the time, no matter what. How do you keep that secure, so that you don't get spammed by any bot on the internet?
- kazen44 5y ago
  a firewall
  - tsimionescu 5y ago
    Peers connect to you by opening a connection to the advertised IP(s) and port. Bots connect to you by opening a connection to the advertised IP(s) and port. How do you tell which is which? With hole punching, at least you have some amount of mutual recognition by using the same external server, and you get some amount of DoS protection from the server itself (though of course the server will likely support many more connections than your local system). So in the end, aren't you more secure using a hole punch method for direct connections over the internet for P2P communication, even on IPv6?
    - growse 5y ago
      > So in the end, aren't you more secure using a hole punch method for direct connections over the internet for P2P communication, even on IPv6? No? It sounds like you're reinventing authentication, badly. If you want to control which clients are permitted to access a service available, we have well-established ways of doing that. Dynamically messing around with the network and "hole-punching" is not one of them (unless you broaden that to mean VPNs, but if you want a VPN, use a VPN!). If you don't want anyone on the internet to be able to SYN/ACK to a TCP service you put on the internet, don't put it on the internet. Also, insert standard soapbox speech here about how the contextless phrase "more secure" is meaningless. More secure against what? What's the threat or risk you're trying to control?

ignoramous 5y ago

> What would a backward-compatible address extension to IPv4 look like? See also: https://en.wikipedia.org/wiki/IPv6_transition_mechanism https://en.wikipedia.org/wiki/IPv6_transition_mechanism

willis936 5y ago

>Empirically, some ISPs route IPv4 more efficiently and some route IPv6 more efficiently. It is so refreshing to see this written down somewhere. All of the academic papers I've seen comparing the empirical routing performance between IPv4 and IPv6 show a negligible performance difference. However, in the two states I've lived where I have looked at IPv6 vs IPv4 performance I see consistently higher pings with IPv6. Traceroute reveals that each individual hop adds the about the same amount of latency, but there are ~15% more hops for IPv6. If I play a competitive game then I don't want to be adding 10 ms of latency unnecessarily. So I just disable IPv6 on my gaming rig? C'mon. We can do better.

rkeene2 5y ago
You can thank large backbone providers for this. IPv6 works just fine over the same L2 link as IPv4, so there would never need to be any more hops than IPv4 (sometimes they do need to upgrade equipment to support IPv6 so they may be DIFFERENT hops over DIFFERENT L2 links, but they could also move their IPv4 traffic to that new equipment). What happens is when the large backbone providers have disputes, the de-peer with each other IPv6, which causes rerouting to be visible. They can't "punish" the other with IPv4 depeering, since that would make their own customers angry.

cube00 5y ago

> Should I support IPv6 on my server? > You can if you want, but despite what some people will claim, it probably won’t make much difference. This apathy is exactly why adoption is slow. For all its faults Google needs to be commended for their commitment to IPv6. They are the only large email provider I see sending and receiving email using IPv6 even though "it probably won’t make much difference"

p_l 5y ago
It also helps when you connect from mobile networks, as due to various things (including, afaik, licensing shenanigans) there's a huge push for v6 in mobile networking. Even your v4 traffic is probably going over v6 using 4x6x4 translation.
willis936 5y ago
It's okay imo. IPv4 on the internet is getting very expensive very fast. The market will do its thing and the solution is already on hand: IPv6. The addresses are virtually free. Sure it's not with all the fanfare and it doesn't meet all of its promises, but it will happen and fast.
- loup-vaillant 5y ago
  Close to 5€ per month for my virtual server. Almost half the total cost. I’m still paying them because I’m not sure people could still contact my web server (and when I used it my mail server) if it was IPv6 only.
zinekeller 5y ago
Mr. cube00, for a static website it's a toss-up (you should activate it anyway if you're able to!). The problem is that (for example) for forums etc., 40-bit addresses (the best-approximation considering that only a slice was allocated and /64 is treated as a single network connection) adds a whole lot of problems when it comes to combating spam etc. 8 bits sounds like nothing to you but you multiplied their problem 256 times. In shorter words, it's not always economical to turn the proverbial switch on. For Google, they can rely on their AIs but for small forums? That's just (unfortunately) an additional attack surface on something that they want to be gone.

anonymousiam 5y ago

I've been playing with IPv6 for over a decade. My observations are that it's actually faster across the backbone. I'm not sure why this is. A very useful site: https://ipv6-test.com/ https://ipv6-test.com/

bombcar 5y ago

Let’s get 128 bits but give everyone a /48 and so have only 16 bits more effectively wooohooo Shoulda gone for 1024 bits and made people really whine

rkeene2 5y ago
Keep in mind this allocation strategy only affects 1/8th of all IPv6 space, so if we picked the wrong one we have the other 7/8ths to use in a (hopefully) better strategy.

lowercased 5y ago

I'm curious when we'll declare some sort of "idea bankruptcy" on IPv6, develop a new version (IPv7?) that has a "ease of migration from IPv4" as a stated goal, and deploy/implement that. Knowing the historical transition issues collected over the past 20 years, we could, as an industry and society, design a next generation and provide a reasonable rollout target of, say, 2030, and move towards that. Since 1998/99, there's been an explosion of networking, and large cultural shifts (billions of mobile devices, IoT, etc) which were not around when all this was specced out. No technology adopted IPv6 as a default during that time, and I dare say most things (services, devices, etc) aren't even tested against IPv6. After 20+ years of this, I see IPv6 as a failure, even if there is 30-50% adoption (or perhaps because of those figures).

jl6 5y ago
With ~30% adoption of IPv6 today, your great new alternative is going to need an “ease of migration from IPv6” feature too.
- zinekeller 5y ago
  Nope, you don't need to, because of a simple fact that there is a very minuscule amount of IPv6-reliant systems in the wild. Most of them also operate in IPv4 (because IPv4 is more prevalent). Name me an existing system where: a) requires IPv6; but b) not because of its long address. Good luck finding such a system.
  - kazen44 5y ago
    mobile telecom gateways? most modern telecom uses ipv6 for LTE communication, with nat64 to communicate with ipv4.
- formerly_proven 5y ago
  Not really, since IPv6 adoption is low, a service that doesn't also exist on IPv4 practically does not exist, so if you have a good migration path (unlike v6) from v4, you're taking approximately all services with you.

zinekeller 5y ago

Sidenote to all of this, an IPv4-compatible upgrade path in 1992: https://datatracker.ietf.org/doc/html/rfc1347 https://datatracker.ietf.org/doc/html/rfc1347

Dagger2 5y ago
Can you explain how it was compatible? That RFC says "Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged." which sounds exactly the same as the way v6 normally does it. As far as I could tell from the RFC, if TUBA counts as v4-compatible then so does v6.
throw0101a 5y ago
This was brought up in another part of the thread. I'm copy-pasting my reply: --- From the RFC (emphasis added): > The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses. […] In §3 Migration: > Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup. So you're replacing IPv4 with something that is not-IPv4 on every router and every host. During the transition period everyone will have IPv4 and not-IPv4 addresses. How is not-IPv4 being CLNP/NSAP any different that not-IPv4 being IPv6? What am I missing? In §6 on DNS: > TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses. Which is basically describing AAAA records. --- * https://news.ycombinator.com/item?id=28326806#unv_28328593 https://news.ycombinator.com/item?id=28326806#unv_28328593

rswail 5y ago

Well it appears that routing to google from home is pretty much the same: ping google.com round-trip min/avg/max/stddev = 5.925/7.695/10.634/2.093 ms ping6 google.com round-trip min/avg/max/std-dev = 6.348/8.013/10.869/1.965 ms traceroute and traceroute6 both had 8 hops.

GenaroHR 5y ago

As someone who experience many problems with Multicast on IPv4 / IPv6 hybrid networks, how different are the implementation of Broadcasting on each protocol? Mostly I came aware that in IPV4 the router tries to create a local multicast group, using IGMP snooping you can solve some problems to get your broadcast thru multiple devices, but in IPv6 this is kind of confusing to me... does any one has information on this?

sophacles 5y ago

I firmly believe IPv6 adoption is hindered by one little reason more than any other: i can't easily remember an ipv6 address. Its too big, its in hex, and that adds friction to everything. With v4 i can just look at an ip, remember it for a second and type it into whatever config/program/etc i need. I can tell a colleague across the room "that ip is:...". I know there's the condensed address format, but that just makes communicating it harder. Typo `::` as `:`? Now you have a problem that's not easy to see. Its a small friction, but it adds up quickly and makes working with ipv6 feel sluggish and painful. (A common response when i say this is "isn't that what DNS is for?" and yes, it is. That's great once you have DNS and reverse DNS working, but "its always dns" is a meme for a reason).

throw7 5y ago

I'm on linux... Is there some document on how I can tell if i'm getting ipv6, a description of what i'm seeing or what to expect, and what I can do with it that is cool?