Hacker News Reader

Comment by gruez | Hacker News Reader

>reduce routing table sizes by using explicit AS routing

>that would require a decent network prefix to AS number lookup service

I don't see the advantage of this. All you're doing is offloading the routing table to every client device rather than at core routers only. Also, the "AS number lookup service" would be like a DNS request, which adds latency to every connection.

> - maybe reduce IPv6 address sizes to 64 bits

why? The only advantage I can think of is that it's easier to remember/enter for humans, which isn't really a good reason because there's DNS anyways.

View on HN

> I don't see the advantage of this. All you're doing is offloading the routing table to every client device rather than at core routers only. Also, the "AS number lookup service" would be like a DNS request, which adds latency to every connection.

The better way to do it is to forget about a lookup service and make the AS number a part of the IP address. This is why you do want 128-bit addresses. You could make the AS the first 32 bits of the address and then each AS would have four billion /64 networks.

But in practice this is basically what you get with IPv6 anyway. The problem with IPv4 is that because there aren't enough addresses, you have people wanting to add dozens of network prefixes to the same AS because they couldn't get a single contiguous block large enough for their needs. With IPv6 you can give every AS a /32 with 96 bits worth of addresses in it and they'd never need another one.

That is genuinely genius. It's just a pity it didn't occur to anyone back in the day.

Edit: OK, not sure why that got a downvote. Did somebody think I was being sarcastic or something?

Well, sure, if address portability doesn't matter. Which... it kinda doesn't, so, sure. But AS numbers don't need to be much bigger than 24 bits, so 64 bits for addresses is plenty :)

Existing AS numbers are 32-bit, but sure, 24 is probably enough.

The problem is with 64-bit addresses you'd only have 40 bits left for the whole AS. They'd quickly run out if they gave each customer a 32-bit block, so they'd have to use 20-bit blocks or so.

Then you have corporate customers who want to do complex internal subnetting, for which 20-bit wide blocks are administratively burdensome. 10.0.0.0/8 is 24-bit and they already run into problems there. They start having to use variable-sized subnets because the main office needs a 14-bit wide block but you don't have enough addresses to give every office that many, and then you have to renumber any time the size of an office changes, and probably renumber two other offices to free up a large enough contiguous address block.

That all goes away if you can give every customer billions of addresses and they don't have to worry about their subnets being "too big" which means they never end up being too small.

ipv4 not having enough addresses is a good thing, with ipv6 censorship and ID can be down to the person globally, but ipv4 is going to force NAT's.

IPv6 has enough addresses to use a different address for every outgoing connection. NAT buys you nothing and is only a horrible dumpster fire.

IPv6 gives you a ridiculously large number of different IPs... but they are all in the same /64, which you can pretty much treat as a single location. So, all these IPs aren’t really adding much to protect someone’s privacy.

The claim was that it made it worse. How is sharing the same /64 worse than sharing the same IPv4 address?

On top of that, you don't actually know that it's a /64. The customer could have a /56. The customer could have a /128, which some mobile ISPs do. The customer could have a /128 with the ability to request arbitrarily many of them from the ISP, allowing the same trick with one IP per outgoing connection but causing the pool to be shared across all the ISP's customers. The ISP could, in principle, allow the customer to request an arbitrary number of non-contiguous address ranges of an arbitrary size and use them for an arbitrary duration before reassignment to a different customer. Nothing really requires it to be a single /64 forever.

1. it forces the banning of a larger group of people because there are more people than addresses

2. its impossible to uniquely globally tag each person with an ip

>why? The only advantage I can think of is that it's easier to remember/enter for humans, which isn't really a good reason because there's DNS anyways.

It'd reduce the size of the IPv6 header, allowing more data per 1500 mtu packet. There's a lot of situations that are bound by packet rate limits, not bandwidth concerns.

BTW, if we're going to radically reimagine the internet, we should really push for a 9000+ MTU.

I think the point of 128 bit addresses in IPv6 is that it is effectively unlimited and thus won't cause problems and can make address allocation simpler.

It's a bit like the maxima in ZFS.

Current technology allows to pick maxima so large that we can just forget about them, so why not do it?

Oh I'm not advocating for it, I'm just saying that'd be the argument. I think avoiding a new L3 transition ever again is well worth the tradeoff.

>It'd reduce the size of the IPv6 header, allowing more data per 1500 mtu packet. There's a lot of situations that are bound by packet rate limits, not bandwidth concerns.

So in cases where we're packet limited and not bandwidth limited we'd get a 1.1% throughput boost (1460 IP payload vs 1476). Seems like a fair tradeoff for never having to worry about NAT or address exhaustion ever again.

1. All Tier1 ISP have mtu of at least 4470 since forever. 2. Most Tier1 ISP have 9000 ip mtu for a long time.

Eyeball networks don't though. In fact, a decent number (at least in the US) still run PPPoE, shaving off even more.

Consumer networks lags badly, indeed. And inventing random new protocols won't fix limitations of MTU.

How does that work with connections (eg. consumer ISPs) that use <= 1500 MTU? If there's even one router in your path that doesn't accept high MTUs, any benefits will evaporate. So basically high MTUs are only really useful for datacenter <-> datacenter connections, where you can reliably get high MTUs throughout the entire path.

So, if we're talking about reworking everything, then ... just burn those middleboxes.

IPv6 already mandates path MTU discovery and min MTU of 1280.

Reply on news.ycombinator.com