4 ms·

> 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

by growse 3y ago

> 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).

FuriouslyAdrift 3y ago
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.
cyberax 3y ago
> 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-down.html 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).
- growse 3y ago
  > 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 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.
  - cyberax 3y ago
    > 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?
    - greyface- 3y ago
      > 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.
      - cyberax 3y ago
        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.
        greyface- 3y ago
        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.

by growse 3y ago

FuriouslyAdrift 3y ago

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.

cyberax 3y ago

> 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-down.html 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).

growse 3y ago
> 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 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.
- cyberax 3y ago
  > 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?
  - greyface- 3y ago
    > 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.
    - cyberax 3y ago
      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.
      - greyface- 3y ago
        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.