This doesn’t seem as simple as sticking your IoT devices behind a /64. Your site should be assigned at least a /56 from your ISP giving you 255 possible /64s. If you need more subnets you need to get a /48 from your provider. And if 2^16 subnets for your IoT devices is insufficient you will need to go to your Regional Internet Registry to get more.
I see this is to avoid issues with Neighbor Discovery Protocol and isolate hosts but to call this simple when you already will need to deploy a security solution(s) beyond subnetting to enforce your network policies is what I take issue with. IPV6 address planning and security is not the same as IPV4.
This talk[0] is an hour long but from 22:18 on they discuss their recommended IPV6 address plan (the whole video really opened my eyes to IPV6 and made it all much more understandable). You shouldn’t subdivide below /64, as RFC 5375[1] does not recommend it and as discussed here[2] there are some pitfalls you can encounter.
This is about connecting multiple networks together and doing routing between them.
If you bridge them all on layer 2, things get messy fast when dealing with busses (see [0]), but if you don't need IPv4 backwards compatibility, you can just use routing and treat each network segment as it's own subnet.
See the talk on last year's RIOT summit about this [1]
> You shouldn’t subdivide below /64
The auto-subnets module won't do that, but it will happily divide the /56 you get from your ISP into multiple subnets without administrative intervention.
> You shouldn’t subdivide below /64, as RFC 5375[1] does not recommend it and as discussed here[2] there are some pitfalls you can encounter.
I disagree, we should be doing that as much as possible. People hardwiring their circuits/software to not allow that functionality is exactly how we end up with huge blocks of unaddressable space in 20 years.
If each RIR is limited to one /3, they can hand out 2^45 /48’s or over 8,000 entire IPV4 worth of addresses that can than be each subnetted 2^16 times and each subnet support billions upon billions of hosts. And if we reserved a private address space at another single /3 like 10.0.0.0 is for IPV4 each one of those billions of hosts could have 2^45 addresses behind them as well. Even if there were 15 billion humans and 15 billion businesses and government entities and so on, a single /3 could provide enough /48s with over a billion of addresses to spare with everyone getting their own /48. IPV6 has no lack of addresses.
Allowing for hosts to use a full /64 allow for additional features such as an “address TOTP” like this[0]. I will concede that they implemented this with just a /80.
And yet many hosting companies are only handing out a /64 to hosts, which some software has issues dealing with less than /64 (if running a vm). Currently companies are buying/selling huge blocks of space, just like the early days of ipv4 (like Apple owning a whole /8 still).
Yes, you logic of "there's plenty to go around" works, until the feast is over and everyone owns something because it is so cheap.
Well that certainly is an issue I can agree with. Properly managed IPV6 has far and away enough addresses. I can see how failing to properly allocate address space can lead to the same issues as IPV4.
> If there are multiple routing nodes on the same link, coordination between the routers is required. For this the gnrc_ipv6_auto_subnets implements a simple UDP based synchronisation protocol where each router announces the number of subnets they want to create.
This is one benefit NAT has, you don't need coordination between routers. That's important in various business environments where you could have 2-3 or more levels of routers, each controlled by different entities. With NAT+DHCP you don't worry about how the public subnet can be divided up, each party just NATs and moves on.
> Unless you need inbound connections. Then you need coordination as well.
Right. In the cases I mention, inbound isn’t an issue. The various entities assume the worst for their routers (outbound only) and use VPNs where they control both sides. So no issues with DHCP-PD or insufficient subnet size allocation.
I see this is to avoid issues with Neighbor Discovery Protocol and isolate hosts but to call this simple when you already will need to deploy a security solution(s) beyond subnetting to enforce your network policies is what I take issue with. IPV6 address planning and security is not the same as IPV4.
This talk[0] is an hour long but from 22:18 on they discuss their recommended IPV6 address plan (the whole video really opened my eyes to IPV6 and made it all much more understandable). You shouldn’t subdivide below /64, as RFC 5375[1] does not recommend it and as discussed here[2] there are some pitfalls you can encounter.
[0]: https://youtu.be/7Tnh4upTOC4
[1]: https://datatracker.ietf.org/doc/html/rfc5375
[2]: https://serverfault.com/questions/714890/ipv6-subnetting-a-6...