Once upon a time, Kenneth Porter <shiva@xxxxxxxxxxxxxxx> said:
> --On Tuesday, April 28, 2020 10:16 PM -0500 Chris Adams
> <linux@xxxxxxxxxxx> wrote:
> >And frankly, giving you a /56 is pretty crappy, since ARIN rules say to
> >give every site a /48. I'd only do a /56 for a home connection prefix
> >delegation. But, that's AT&T! :)
>
> I'd just read about that when researching this. Maybe they decided
> that since we only have about a dozen people at our site, we won't
> have a lot of subnets. What do small offices DO with 256 public
> subnets, anyway? I suppose eventually we'll have an IoT subnet on
> every person.
The idea with IPv6 is not to even necessarily think about it in terms of
direct numbers, but in layers. It is not uncommon to have several
layers of routers, firewalls, guest wifi networks, etc., and each layer
should request a prefix delegation from its parent. So rather than 256
subnets, think about it as 8 layers (at most... but if a layer has more
than 2 children, you have fewer layers available).
So for example, if your Internet gateway has a desktop firewall, a guest
wifi, a public DMZ, and a development lab gateway connected, and you
want to allow for more things at that layer, there's 3 of your 8 bits in
a /56. If the dev lab needs to fan out more, and maybe your public DMZ
needs to break up for production and QA-testing networks, and you add a
VPN concentrator to the desktop network... you can go through those bits
fast.
In IPv4, people would just NAT the crap out of everything, having to
tunnel from one NATted network to another, making life really difficult.
The plan is no NAT in IPv6, so allow for all potential allocations up
front.
Also, allocations should be larger than necessary and sparse, so that
you never need another allocation (even if you grow to 1000 employees
and multiple buildings on a campus). This is to hopefully prevent
routing tables from exploding like IPv4 did (and also to avoid you
having to renumber everything just to stay in a single block).
--
Chris Adams <linux@xxxxxxxxxxx>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
