81–90 of 154 posts
Yet adoption is still growing exponentially https://www.google.com/intl/en/ipv6/statistics.html It's not as fast as past me would have hoped for and I think the criticism is perfectly valid but I'm quite happy to look at this graph no and again
Earlier quoted context omitted.
https://tools.ietf.org/html/rfc4941 defines IPv6 privacy extensions, which mitigate that issue. One of the few benefits of an extended roll-out of IPv6 is that there's been time for people to identify issues like this and get fixes rolled out widely before systems started relying on the old behaviour.
What percentage of IPv6-supporting routers have implemented and activated those privacy extensions?
What we should take away from the IPv6 debacle is a fine lesson in hubris. I was hanging out in the IPv6 mailing lists at the time the various solutions were being debated. The prevailing attitude was "the Internet is about to die from routing overload without IPv6, so we can stick whatever complexity we want inside it, and they will have no choice but to accept it." Except that new router hardware and new incrementa…
Performance? How exactly is ipv6 more performing? It even has bigger headers. Why would ipv6 be more reliable than ipv4? I’d say it’s the opposite: many times I’ve found websites with AAAA registers that pointed to a dead server. I mean, if you’re going to blame cgn for your problems, let’s steep to your level. Analytics? Forensics? So you’re telling me ipv6 destroys my privacy. How is that a pro argument?
This is something I don't really see anybody mention, but IPv6 doesn't allow packet fragmentation as far as I know -- which means you don't get the sudden performance degredation (and extra data loss probability, etc.) that comes with using the wrong packet size. I expect that boosts performance but I haven't had a chance to measure.
Yet adoption is still growing exponentially https://www.google.com/intl/en/ipv6/statistics.html It's not as fast as past me would have hoped for and I think the criticism is perfectly valid but I'm quite happy to look at this graph no and again
https://ripe76.ripe.net/wp-content/uploads/presentations/9-2...
It is actually growing slower and slower and looking as a logistic curve, which is perhaps unsurprising. Also note the increasing gap between weekdays and weekends, which is a sign that enterprises don't care about v6.
Earlier quoted context omitted.
This, whilst technically correct, isn't necessarily end-users experience of things. Yes NAT doesn't block packets, however without explicit configuration traffic from the Internet will be very unlikely to flow into an RFC1918 addressed network from the Internet. So effectively it does prevent traffic inbound in the same way a firewall does. Yes you can punch holes in NAT, but that's an explicit action (well side-step…
> Yes you can punch holes in NAT, but that's an explicit action (well side-stepping the insanity that is UPnP) for for non-technical users sitting behind a NAT router will effectively mean that they're unlikely to receive direct inbound network attacks from the Internet. Hole punching the NAT does not mean that the user will configure port forwarding. It means that the outside is able to send packets inside, without…
That is completely untrue. The vast majority of home routers (I would venture 99% of them) run Linux, and use the built in NAT, which does check source IP, for both TCP and UDP connections.
NAT is not a firewall, and many NAT implementations will let packets in through _if_ you know the internal IP, _and_ all routers along the way including the last one support source-routing -- which is definitely not most setups.
Furthermore, quite a bit of the home users using IPV4 these days are behind a CGNAT, which makes this even harder, as you need to source route through multiple NATs.
Hole punching without cooperation from the inside is not impossible, but it is extremely hard these days, to the point that unless its an ultra-targeted attack, no one is likely to try.
What we should take away from the IPv6 debacle is a fine lesson in hubris. I was hanging out in the IPv6 mailing lists at the time the various solutions were being debated. The prevailing attitude was "the Internet is about to die from routing overload without IPv6, so we can stick whatever complexity we want inside it, and they will have no choice but to accept it." Except that new router hardware and new incrementa…
I've enabled ipv6 on my ubuntu server recently and it was 100x slower. The only solution I found is to go back to ipv4: https://askubuntu.com/questions/759524/problem-with-ipv6-sud...
I just updated from 2001:878:346::116 / mirrors.dotsrc.org; no problems.
Which mirror were you using, and did you file a report?
Earlier quoted context omitted.
Can't use 172.16.0.0/12 either? That's over 1m hosts. You don't have 1m hosts unless your homelab is actually a large domestic ISP.
Either way I'd have to renumber everything. If I'm going to do that why wouldn't I just go straight to IPv6? I already have IPv6 on my home network (but everything has an IPv4 primary address and name resolution always resolves to IPv4); and an IPv6-supporting ISP. The question is if it's a good idea to go IPv6 only for some or all machines, and how to deal with the IPv4 IPv6 issues.
> If I'm going to do that why wouldn't I just go straight to IPv6?
Because it is a lot more than just renumbering.
Whether or not it's a good idea depends on what you expect to get from it (anything?), how good your ISP's IPV6 support is, and how good the support of hosts you connect to is.
If whatever hosts you contact are all on IPV4 only, then you'll have to occasionally debug the 6to4/4to6/Teredo/whatever kludges that add latency and provide nothing of value compared to using an IPv4 directly.