Hacker News Reader

Comment by cyberax | Hacker News Reader

8 bits for the home network feels cramped even now, my home network is at 56 devices. But 16 bits are fine for end-user networks.

And once you go over 16 bits, you really need to start dealing with routing.

> In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough.

This is not a fair comparison. You won't have a 10.0.0.0/8 network in IPv4 that has 16 million computers in the same broadcast domain. You'll likely have multiple /8 or /16 networks, with routing between them.

And in my hypothetical world, you'll have 56 bits for that routing. Your ISP can delegate you a /32 prefix, giving you 24 bits for your own routing hierarchy.

This is not dissimilar from the current situation. You have just 64 bits of the "network address", because the lower 64 bits are needed for SLAAC.

View on HN

Large, sparse subnets are nice for their security benefits.

For a 16-bit network, you can enumerate all active public servers by exhaustively port-scanning it; it takes something like a few hundred gigabytes of traffic, which is nothing these days. For a 64-bit network, it takes quadrillions of gigabytes of traffic and just isn't feasible.

64 bits is enough space to fit a small public key, which v6 uses to secure neighbor discovery.

There are anonymity benefits too: privacy extensions wouldn't work as well on smaller subnets.

As an added bonus, having extra bits to spare is useful if it ever turns out that we need them. If we run out of space in 2000::/3 then we can start over in one of the five other unused /3s using tighter allocation policies. L3 protocols are incredibly hard to deploy and it would really suck to deploy a bigger one only to have to deploy another, even bigger one again soon after.

I don't think there's a good reason to give up all of that. Smaller addresses break compatibility with v4 just as thoroughly as bigger ones do, so it wouldn't even help deployment much.

> And once you go over 16 bits, you really need to start dealing with routing.

Disagree. you don't want to be routing unless you actually have to. A large flat network is more desirable a lot of the time (e.g thousands of devices in a DC) than a bunch of artificially carved up subnets.

The reason you don't see them very often is because people have had to use IPv4, which means ARP, which just doesn't scale. At some point in size, ARP chatter becomes the majority of the traffic on your network, which isn't great.

ND fixes this, and allows for ridiculously large networks (the way our good maker intended).

Except security... every network I build, ALL traffic between hosts/apps must go through an inspection device.

Due the mass use of encryption and overlays, you can't trust any process or device any more.

> Disagree. you don't want to be routing unless you actually have to. A large flat network is more desirable a lot of the time (e.g thousands of devices in a DC) than a bunch of artificially carved up subnets.

First, a /16 network is 65536 devices, which is pretty big as-is. And like in V4, you'll be able to disregard recommendations and choose a larger local net size (just change the netmask).

But it's a bad idea. You will have a shared media that can be brought down by erroneous broadcasts or devices. This is a classic story: https://www.computerworld.com/article/2581420/all-systems-do...

> ND fixes this, and allows for ridiculously large networks (the way our good maker intended).

ND doesn't solve it. It works in practice using the same old broadcast, just like ARP. Some switches might do ND snooping, but if you have thousands of devices, they'll overflow their internal tables and fall back to regular broadcasts.

ND also has unsolvable issues, like the neighbors cache size problems. Since you have a freaking /64 for your local network, you can't easily store the mapping for ALL hosts, and you're susceptible to various cache exhaustion attacks (including negative entries).

> First, a /16 network is 65536 devices, which is pretty big as-is.

"big" is a relative term. For some cases, that's a really annoying restriction.

> But it's a bad idea. You will have a shared media that can be brought down by erroneous broadcasts or devices. This is a classic story: https://www.computerworld.com/article/2581420/all-systems-do...

IPv6 doesn't have the concept of "broadcast".

> ND doesn't solve it. It works in practice using the same old broadcast

No, ND uses multicast.

Running any network with >100k hosts has its challenges, but these are surmountable with IPv6, and not at all with IPv4.

> IPv6 doesn't have the concept of "broadcast".

Indeed. It has magic fairies delivering multicast packets to the right interfaces.

> No, ND uses multicast.

How do you think multicast is implemented in Ethernet?

> How do you think multicast is implemented in Ethernet?

Via MLD snooping on switches that support it. Yes, some switches will fall back to broadcast, but only if they're not multicast aware.

Snooping table sizes are typically around 16k entries. IGMP/ND packets are almost always punted to the CPU, so once the CPU is saturated, switches typically either fall back to broadcast or stop forwarding multicasts.

It's not a good outcome either way.

This varies widely by switch model, and 16k is on the low end. I looked at a few random Cisco and Arista switch datasheets just now and saw numbers ranging from 16k to 768k (usually 25% to 100% of the unicast MAC table size of the same switch).

Unicast MAC table space is scarce, too, and suffers the same failure modes when filled. You don't see people claiming this makes IPv4 over Ethernet infeasible. Do proper capacity planning, and this isn't a problem. Oversubscribe your network, and this is a problem even without multicast in the picture.

> Unicast MAC table space is scarce, too, and suffers the same failure modes when filled.

Yup.

> You don't see people claiming this makes IPv4 over Ethernet infeasible

Actually, people DO claim that. Flat Ethernet doesn't scale, and you need to use routing to break up broadcast domains.

> Actually, people DO claim that [MAC table limits make IPv4 over Ethernet infeasible]. Flat Ethernet doesn't scale, and you need to use routing to break up broadcast domains.

This has nothing to do with unicast MAC table limits, and everything to do with ARP's O(n^2) scaling property. You use just as many MAC table entries in a network with 10 VLANs of 100 hosts as you do with 1 VLAN of 1000 hosts. Ethernet scales fine; ARP doesn't.

16 bits is fine if thinking about discrete devices in the home.

But what about thinking about the next step, neurons in the home. 65k's on the low side for home neuron count.

Are you sure you want to expose individual neurons to the Internet?

Think of the unexpected unknowns. The feet of your chairs having light sensors, each tile of a roof having its own ambient vibration monitors, a thermostat on every bookcase shelf, all self organising around the you GooFaceAI determines you to be.

Reply on news.ycombinator.com