o1bigtenor via Dng <dng@???> wrote:

> My present thinking is to use 172.16/19 - - - that gives lots of
> address space without
> throwing the door wide open either.

Couple more thoughts ...
Firstly, think big - for most users the RFC1918 space is plenty big enough. It’s less of a problem to configure more space than you need now than it is to go round changing the netmask (and in a typical business setup have to pick a new address range) to expand it later.
Using a large address space allows you to be “wasteful” by using a logical addressing scheme. E.g., you might decide to allocate a block of 16 addresses per cell even if there’s only (say) 6 devices in there. That way, you know your devices are at ac:16:xx:xs (that’s 172.16.blah.blah in hex) where xxx is the cell number and s is the sensor - I tend to think in hex and/or binary, it’s much easier handling other than byte boundaries in netmasks.


> Last idea I ran into was a dual-protocol network (both ipv4 and ipv6.

For this setup, and assuming it’s not going to be connecting to the internet, I wouldn’t bother with IPv6. The RFC1918 address space is more than big enough for you, IPv6 will consume more resources in the devices (and some might not even support it at all), and it won’t really give you any benefit.


> I do want to be ready for a reasonably painless switch to ipv6 - - -
> the impending isp is working on it but likely dragging their feet so
> I will have time to get things started in ipv4 - - - I think.

As mentioned, you can bypass your ISP with a service such as tunnel broker.net. Nut I’d stick to just your other stuff and leave your industrial stuff on IPv4 - it’ll save you a lot of hassle.


>> To a certain extent, a lot of this depends on how the devices logically group.
>> If, for example, each “cell” had a few hundred devices - then it might make sense to put each cell on it’s own network and have a lot of networks.
>> On the other hand, if there are only (say) 2 or 3 devices in a cell, then you’d put a lot of cells in each network.
>> There isn’t a “right” answer - it’s a case of looking at what you are looking to connect, and trade off the various options to arrive at what you consider the optimum solution (given your idea of how the different factors should be weighted).
>>
>
> I'm starting with 4 to 6 working points per 'node'.
> Looking down the road that might escalate - - - - if it gets to 10 to 16 then
> I think it would make sense to have a switch (thinking a 24 at this point) per
> 'node'. (By that time there would also be some more interspersion of
> 'servers' (for lack of a better term).

If you got to (say) 10 devices/cell then you might use a 24 (or 24+n) switch between two cells. To a certain extent it depends on how the physical arrangement suits. E.g. if the cells were a distance apart, at some point it becomes easier to have one switch/cell and one uplink than to have multiple longer cables between each sensor/device and a shared switch. While if the cells are close together, it’ll be simpler to have a larger switch shared between multiple cells.
If you did segment the network, then the devices to do that would be routers (without using NAT). It’s not much setup, it still allows any-to-any communications, but it reduces the broadcast domain size and localises certain types of network problems.



> Interesting ideas - - - thanks for the time sir!!!

You’re welcome. TBH, it’s interesting to have a question like this and have a chance to toss ideas around.


Simon