Hacker News Reader

Comment by est31 | Hacker News Reader

One of the ideas of ipv6 was to reduce routing tables, those tables that backbone providers have to keep in memory and look up for incoming traffic. With ipv4's fragmented allocation scheme, these routing tables are huge. With ipv6, even huge companies like amazon only have a couple of global allocations. A "ipv4 with more octets" scheme would have kept that fragmentation around.

That being said, Amazon currently has 2880 ipv4 allocations and 946 ipv6 allocations... not much gained I guess? :p https://asnlookup.com/asn/AS16509/

Also, there are definitely some horrible ipv6 warts, like that the only standard for local ipv6 addresses forces you to adopt a scheme where your local address is horribly long, for the sake of global uniqueness, which is something that most people don't really need.

View on HN

Amazon is really not a great example, I don't think. The giant cloud providers are outliers with respect to DFZ announcements, as they have many, many POPs and also allow their customers to announce address space. They're more like transit networks at this point than what could be reasonably considered a representative end user.

More reasonable to look at announcements per AS, where it's currently about half of IPv4, but trending upwards at a faster pace.

v6: https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata... v4: https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata...

So Amazon with its 3-fold ratio is in fact giving a better argument for ipv6 than the average, nice. Generally a factor of two doesn't say much about ipv6 creating less allocations at all, given how ipv6 is roughly within a factor of two in terms of adoption in general.

> One of the ideas of ipv6 was to reduce routing tables

That idea was abandoned about 20 years ago. One fairly quickly discovered that hierarchical routing does not work well in the real Internet, where redundancy is done on the IP level with everybody and their dog having provider-indepent IP space.

> like that the only standard for local ipv6 addresses

Which one is the only standard? Link-local, site-local, ULA, or using a non-routed netblock with or without DHCPv6 (or RA)?

site-local addresses are deprecated since RFC 3879. Link-local addresses are indeed another standard, but have the very same length problem. You have these horribly long ipv6 addresses... those can't reasonably be parsed by humans... There is no 192.168.* equivalent in ipv6. Why don't we have something like fd00::1 being the router and fd00::2, fd00::3, etc being the devices in the local network, assigned by DHCP. You can absolutely configure your router that way but it is violating a MUST requirement of RFC 4193. That's my point. There is no non-routed netblock where you can just use it for local purposes, outside of the one for SLAAC and the one for ULA, both creating these horribly long monsters of addresses. All the others have purposes attached that are not meant to be used for local networks.

Why do you care how long the addresses are? That's what DNS is for. Within a link - most home networks are only one, and those are the ones that need to be simplest - there's even mDNS.

DNS is great but it is not available in all settings. Eventually you need to type in ip addresses, there are gazillions of workflows where you have to do that.

There's only a very few places where typing IP addresses actually makes sense. Configuring DNS is the main one. Trying to isolate problems is another - if you can ping 8.8.8.8 but not google.com you can reasonably infer that the problem is DNS. I really can't think of any others.

That latter one is admittedly kind of a pain, but a wallet-sized cheat sheet can solve it for you. Might be a good idea to try to convince vendors to include a reliable entry or two in the hosts file for that purpose? You can always add it yourself for now, when you're on your own workstation.

> where your local address is horribly long, for the sake of global uniqueness, which is something that most people don't really need

Apart from debugging where you can copy-paste anyway, does it matter? I've got a few services on the local network and over zerotier that all talk IPv6. In the last 3 years or so I've never used an ipv6 address directly. There's enough DNS and discovery protocols that I never needed to.

Plus if you're using enough IPv4 addresses it is going to be the same problem anyway. I can barely keep track of what I've assigned everything to in just a /24 so I have local DNS and I don't need to.

Any sysadmin for a medium sized company with their own servers are likely to end up having to type in IP address or get them off shitty management consoles that don't support copy paste in any way.

Using IP addresses directly is a bad practice in general, it introduced security risks in many scenarios.

SSL - usually cannot verify the cert, defeating the point of SSL SMB - windows will fail over to less secure ntlm auth instead of kerberos

If your using IP addresses instead of hostnames to reference machines, you're doing it wrong.

Also IPv6 is easier to remember in general... We have a single large IPv6 allocation (eg 2001:db8::/32), and everything sits under that in a logical layout. For legacy IP, we have several different allocations in different class A blocks (104.x, 66.x, 62.x etc) plus all the RFC1918 space used internally

Sure, but most places are not setup to using DHCP on servers or automated installs. So you will be typing in IP addresses through some kind of console to configure the machine in the first place and you will be typing in that IP address in the DNS system and when someone remotely fucks up the routing or IP config then you will be manually typing in lots of IP addresses to fix it.

If you have enough nodes to care and manually assign and at the same time don't automate deployment that sounds like an issue in general... and not with IPv6. You're likely to typo IPv4 just as well with enough entries.

Yep, but in my experience you have to manage about 2000+ machines before management will allow you to spend time on setting up deployment automation. So around the time you are setting multiple new machines a week.

I've done automatic deployment for 16. It was still totally worth it.

Of course it is, automation is very nice, I use it for the handful of machines I have my personal stuff on. I am just saying that from my days as a sysadmin it was usually a years long uphill battle to get approval for automating even minor things.

> That being said, Amazon currently has 2880 ipv4 allocations and 946 ipv6 allocations... not much gained I guess? :p https://asnlookup.com/asn/AS16509/

I remember the line being "the IPv4 routing table is 3x as big as it needs to be due to fragmentation", so that seems pretty in line with that.

I'm not up to date, but when I knew about this stuff the cost of memory for routing tables was only a tiny, tiny fraction of the cost of a network. Most of the cost is burying and maintaining fiber.

So unless something big has changed, it seems like a terrible choice to twist the whole system into uselessness to try to save a small amount of RAM cost.

According to this Stack Exchange post from last year a full IPv4 routing table requires on the order of a few hundred MBs of RAM. This is indeed a tiny fraction of the cost of maintaining the global internet infrastructure.

https://networkengineering.stackexchange.com/questions/76562...

The problem is that the routers that have to hold the routing table can only handle a limited number of routes. There is a good article from APNIC about the topic.

https://blog.apnic.net/2021/03/03/what-will-happen-when-the-...

Said routers could be redesigned...

And besides, there is no need to keep the whole routing table in RAM. Instead all that's necessary is a single integer per route representing which port packets to each route needs to be sent down. So even for a large router with 64 ports, the whole routing table fits inside 1 megabyte.

Sure they can create routers with more space for the routing table but you still have to replace all the old ones which isn't cheap.

A single port of a router at an internet exchange can reach more than 1000 different routers. A router has to decide to which IP it should forward a packet not just the port.

It's not "twisted into uselessness"... the reduction in routing table size comes from the large address space. No twisting was needed.

Also, the routing tables we're talking about here need to be stored in TCAM. Content-addressed memory is a lot more expensive than regular DRAM.

> That being said, Amazon currently has 2880 ipv4 allocations and 946 ipv6 allocations... not much gained I guess? :p https://asnlookup.com/asn/AS16509/

How many clients can those IPv4 allocations serve? How many clients can those 946 serve?

If Amazon had 2880 IPv6 allocations, how many clients could they serve?

I'd say a lot was gained. Someone asking for a random PI IPv6 allocation gets, at minimum, a /48 for a "site". That's the equivalent of a Class A (16 bits for subnets).

Are you saying everyone being able to get their own Class A equivalent is 'nothing gained'?

> Amazon currently has 2880 ipv4 allocations and 946 ipv6 allocations... not much gained I guess?

Whole IPv4 address space is 4294967296 addresses.

A single /48 is 1,208,925,819,614,629,174,706,176.

And 2804:800::/32 is 79,228,162,514,264,337,593,543,950,336.

Gp comment refers to the number of routing table entries, not total number of addressable ips.

Ideally the number of ipv6 allocations should be close to 1 rather than close to 1000.

Reply on news.ycombinator.com