Inform HN: Hacker Information now helps IPv6

Phil Tadros · January 22, 2024

2024-01-22 21:00:15

IPvFoo author here. The problem is that there’s no way to obtain the (hostname, ip) stream from Chrome/Firefox without requesting the “all websites” permission.

In theory, browser vendors could define a narrowly-scoped permission that only reports (hostname, ip), or roll this functionality into the browser UI, but neither seems likely to happen.

I made IPvFoo to promote IPv6 adoption, and wouldn’t consider selling it for less than $10M USD. It probably won’t ever be worth that much because it’s an easily-cloned utility without a “moat”, but it’s more rational to set a price than refuse to sell under any circumstances.

The danger with extension acquisitions is malicious buyers, who use their ability to run arbitrary code to steal credit card numbers or credentials, insert or replace ads, run cryptocurrency mining, etc. For malicious purposes number of installations is the important thing, not how clonable the extension is.

As someone who grew up on IPv4, i will miss it, but the leap to 340 undecillion unique addresses is exciting in many ways so i think i can learn to live with this transition. If we ever need more than that, i can’t even imagine what that future would look like.

The last time I looked into this (which was a few years ago), ISPs were allocating blocks containing billions of IPv6 addresses to anyone who paid a nominal sum.

So that vast address space might not last as long as it would seem…

One of the features of IPv6 is address autoconfiguration, obviating the need for a central authority like DHCP on v4.

However, that only works with a /64 prefix and given that larger sites might want to have multiple subnets, that’s why most assignments are /56 or /48.

But still. If all assignments were /48s, that would still leave room for 281 trillion networks which even I believe is enough for the foreseeable future.

If the number space is so big, it makes sense to take advantage of it if that allows for other additional features (like SLAAC)

Published guidance says they’re meant to give out at least a /56. I don’t know that making autoallocation work on smaller subnets would help with this problem – ISPs that currently give out the smallest possible subnet would probably just switch to whatever the new smallest possible subnet was.

On Comcast Business the SLAAC would hand out a /64, and DHCPv6 would give you a /64 unless you requested “Prefix Delegation” in which case they’d give you a /56, /58 or /60 depending on how large your static IPv4 allocation was.

CIDR and the resulting address space fragmentation was the problem that IPv6 was originally meant to solve; allowing splitting into random-sized subnets makes routing more complex and worse. And if you made the routable part of an IPv6 address longer than 64 bits then that makes the routing much more compute-intensive. 64 bits in the local part of the address is sort of overkill, but a 128 bit address isn’t really any harder to use than a 96 bit address, and it means things like, well, being able to automatically assign the local part based on the MAC address, which only works if the local part of the address is more than 48 bits.

That sure sounds like a lot. But “billions” is less than a /64. Try “sextillions” (/56) or “septillions” (/48). Of course, when the denominator is “undecillions”, it becomes clear that this is actually a non-issue.

Billions of addresses might seem like a lot, but every IPv6 network has at least 2^64 addresses and it doesn’t make much sense (to me) to give any customer less than one network.

(Maybe you meant billions of /64 blocks? ISPs could be providing a /32 ≈ 4 billion /64 blocks, though there still are 2 billion of those in the entire IPv6 space)

Technically the goal of enabling IPv6 can be done through Cloudflare as well, which they enabled a few days ago. I wonder why they turned it off and are back to directly serving traffic.

My concern is that this is an accidental part of an unrelated migration and will quickly be disabled because of some internal IP filtering/banning tool that was only ever written to work with IPv4.

Does ipv6 result in higher latencies? I could see larger addresses increasing latency, but then again I could also see a more efficient protocol resulting in lower net latency. I should probably read a book describing the differences.

Real-world latency is impacted by configuration and hardware (e.g. your ISP may have different routes for IPv6 that can be either better or worse, it can be handled by different routers with different performance, etc) that dwarf any theoretical differences.

Google’s IPv6 stats also measure latency compared to IPv4 and in most countries IPv6 has lower latency (e.g. in the US on average you get 10ms lower latency with IPv6). When this chart was new it was mostly the other way around, with early IPv6 implementations being poor https://www.google.com/intl/en/ipv6/statistics.html#tab=per-…

In theory, any impact from longer addresses would be outweighed by the benefit of the shorter non-CIDR routing table (and in turn that should be outweighed by avoiding NAT, and that should be outweighed by avoiding CGNAT). (Plus with most systems being natively 64-bit these days, that impact should be 0 – the routable part of an IPv6 address is 64 bits, and comparing a 64-bit value is no harder than comparing a 32-bit value).

In practice IPv6 is newer, which has good and bad sides; IPv6 routing paths are more likely to be using newer (and therefore faster) equipment, but there’s also a bigger risk of someone making a mistake that messes up your routing/latency, particularly if your ISP hasn’t been doing IPv6 for very long.

The address space has very little effect in the real world. Other latencies far outweigh anything measurable by having slightly more bits in the address.

Eg: Sometimes IPv6 is faster due to routing differences.

That makes sense. I’m very curious about real-world studies. As a gamer, I’m especially interested in the affect ipv6 has on UDP for real time gaming applications. That’s an area where even 5ms can have an enormous affect on the experience.

20 bytes / 1 Gbps = 160 ns per hop. That’s 0.016 ms additional latency over 100 hops.

On the internet, most links are faster than 1 Gbps and most paths are shorter than 100 hops, so that’s a conservative estimate.

Next is TLS 1.3 support, hopefully 🙂

# openssl s_client -connect news.ycombinator
.com:443 -tls1_3
CONNECTED(00000003)
4160736388:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1562:SSL alert number 70
—
no peer certificate available
—
No client certificate CA names sent
—
SSL handshake has read 7 bytes and written 244 bytes
Verification: OK
—
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

Can you explain this more? Why are you so tied to ipv4?

I recently enabled IPv6 on my home network, and roughly 30-40% of all internet traffic goes through IPv6. Things are noticeably faster, especially connection times to online games on Xbox Live.

My only complaint is that my ISP keeps changing the prefix every quarter or so, so my static addresses need to be updated in the firewall and other places. I am looking into link local addresses but the cocktail of tech is tricky.

You want a ULA (unique local address) instead of link-local.

Link-local can sometimes mean needing to append the interface name to your address and a bunch of other weirdness. If you pick a ULA prefix and announce it (or assign some statically) everything pretty much just works.

I’ve been using them internally for over a year and it’s been great, they basically feel like RFC 1918 addresses.

+1. Link local is like connecting to a computer by mac address. The only time you’d ever want it is if you for some ungodly reason are worried that all other addressing systems have failed, or to bootstrap said systems.

On networks using NAT64 (and maybe also for DS-Lite, although I’m not so sure there), the IPv6 path is more direct than the IPv4 one since it doesn’t need to go through a CG-NAT, which might be at capacity (tracking every TCP connection requires memory) or located farther away than the nearest IPv6 egress router, making routing more indirect.

I believe all three large US mobile carriers use NAT64 at this point exclusively, and CG-NAT is quite common in DOCSIS cable networks.

Simpler routing because address blocks are not fragmented. IPv6 does not have a header checksum so that’s one less task for routers. Packet fragmentation is no longer done by routers. IPv6 capable gear tends to be newer and higher performance. There’s no NAT step or even worse CGNAT.

For those that were wondering: Unlike in IPv4, IPv6 routers never fragment IPv6 packets. Packets exceeding the size of the maximum transmission unit (MTU) of the destination link are dropped and this condition is signaled by a Packet too big ICMPv6 message to the originating node, similarly to the IPv4 method when the Don’t Fragment bit is set.

Sometimes networks will route IPv6 traffic over different paths compared to IPv4 although that could actually be either an improvement or an regression depending on which gets the better path.

IPv6 was a lot more than a numbering scheme, there are performance (and security?) improvements in a number of aspects of IP networking, like more compression in parts of the messages IIRC.

> Can you explain this more? Why are you so tied to ipv4?

For me, IPv4 doesn’t break the privacy barrier, IPv6 blasts a huge hole straight into each and every household, office and IoT device on the planet. No, privacy fixes put into IPv6 do not work.

Can you explain this more? I realize that one IP address per device poses a major problem for privacy, but I thought we somewhat mitigated that by dynamically reassigning IPs.

What exactly is the problem with the privacy fixes that were put into IPv6? Why don’t they work?

I’m guessing that the GP is talking about the fact that if there were two persons in a household using the Internet at the same time, with IPv4 they would connect from the same IP address (though of course with different port numbers), but with IPv6 they would likely connect from distinct IP addresses, and usually only sharing a /64 prefix.

You are correct that this isn’t a big issue. SLAAC addresses are generally changed fairly frequently by the OS.

The next few months may be hard for you. AWS will start charging for ipv4 on February 1st, so it’s likely that either a mass migration is coming or prices for many services will increase accordingly to pass that cost along to customers.

AWS doesn’t have good enough IPv6 support for an exodus from IPv4. ALB does not support IPv6-only. Cloudfront only supports IPv4 origins. API Gateway only supports IPv4.

Given that this was AWS doing what their top two competitors were already doing, and that for most people it’s smaller than the price hikes GCP customers have had last year and coming February 1st, I’m skeptical that anyone significant is going to make this the issue they leave over.

You’ll get a lot of hate for it, but I think you’re speaking the truth. IPv6 is probably one of the worst modern standards (tied C++ templates). Nobody has ever made a convincing argument about the advantages of it over IPv4. Just another case of fools admiring complexity. PHB types love it even more, it’s filled with buzzwords like the “future” of networking.

Source Link

What's Your Reaction?

Leave a Reply