Return to Answer

I would consider a network design that brings along overlapping addressing by design harmful. Avoid it like the plague. In new/fresh designs, avoid NAT. Imagine the pain when you discover that one of the applications does not cope well with NAT and/or port forwarding.

I would suggest (and now this is getting opinionated, hence possibly off-topic)

Use some features only IPv6 can offer, and go IPv6-only for a modern network.

• each module gets an IPv6 capable router as entry/exit point towards the common network.
• towards the module, the router exposes as many VLANs/subinterfaces/subnets as needed, to accomplish the inta-module split of business/data/control "zones". Some rough-hewn access-lists or a firewall (e.g. ZBFW, if it's a Cisco) ensure that traffic cannot be forwarded between zones, but only to/from the central network (or the respective "zones" thereof).
• the router acts as DHCPv6-PD (prefix delegation) client towards a DHCPv6 server in the common network, requesting the delegation of a suitably sized IPv6 prefix.
• using appropriate mechanisms (i.e. a dynamic routing protocol), the central network then ensures that routing information for the freshly delegated prefix is disseminated appropriately (i.e. all routers participating in the common network eventually know that prefix 2001:0db8:000a::/48 is now reachable via router "A" and they know how to reach router "A" .) There are many different ways to accomplish this, all depending on how the common network is built (a flat LAN? a somehow emulated/stretched broadcast domain instead of a LAN ? PPPoE Sessions to a number of concentrators? a bunch of serial lines with PPP? an MPLS L3-VPN? Some MetroEthernet L2-service by a carrier? ... the possibilites are endless).

The router and the given module's systems then ensure that every system within the module gets predictable IPv6 addresses.

1. Either by being a stateful DHCPv6 server, assigning leases as <DelegatedPrefix> + <predefinedHostID> (although, that might be a bit of a challenge on its own there, attempting to set up a stateful DHCPv6 service based on a DHCPv6-PD delegated network prefix with just the HostID part being preconfigured/fixed)
2. Or by implementing something like Linux's ip token on the end systems, where the end system does SLAAC to learn the current subnet prefix, but then tries it's own manually predefined HostID, performs DAD with that and brings up the IPv6 interface.

So much for (somewhat) preditctable addresses, With IPv6, having predictable addresses does not offer too much added value - it's still a bunch of Hex digits no one can remember. Enter DNS.

Some DNS magic might be advisable. Once the central DHCPv6 server assigns prefix 2001:0db8:000a to router "A", it could proceed with a script that generates a set of pre-known AAAA records like <oneOfTheKnownEndSystemNames>.moduleA.internal.myscadanet.tld, with each a ressource record of 2001:0db8:000a:<ModuleInternalPrefix>:<givenHostID>. That's probably best done with DDNS (research topic: Dynamic DNS updates, not the DynDNS style HTTP update thing). That script may reside on the DHCPv6 server itself, which would in turn be the only system allowed to dynamically update the neighboring DNS server.

Hm. A bit on the progressive side, all of this. But still - this is the 2010's. IPv6 is a thing. Talk to your vendors.

I would consider a network design that brings along overlapping addressing by design harmful. Avoid it like the plague. In new/fresh designs, avoid NAT. Imagine the pain when you discover that one of the applications does not cope well with NAT and/or port forwarding.

I would suggest (and now this is getting opinionated, hence possibly off-topic)

Use some features only IPv6 can offer, and go IPv6-only for a modern network.

• each module gets an IPv6 capable router as entry/exit point towards the common network.
• towards the module, the router exposes as many VLANs/subinterfaces/subnets as needed, to accomplish the inta-module split of business/data/control "zones". Some rough-hewn access-lists or a firewall (e.g. ZBFW, if it's a Cisco) ensure that traffic cannot be forwarded between zones, but only to/from the central network (or the respective "zones" thereof).
• the router acts as DHCPv6-PD (prefix delegation) client towards a DHCPv6 server in the common network, requesting the delegation of a suitably sized IPv6 prefix.
• using appropriate mechanisms (i.e. a dynamic routing protocol), the central network then ensures that routing information for the freshly delegated prefix is disseminated appropriately (i.e. all routers participating in the common network eventually know that prefix 2001:0db8:000a::/48 is now reachable via router "A" and they know how to reach router "A" .) There are many different ways to accomplish this, all depending on how the common network is built (a flat LAN? a somehow emulated/stretched broadcast domain instead of a LAN ? PPPoE Sessions to a number of concentrators? a bunch of serial lines with PPP? an MPLS L3-VPN? Some MetroEthernet L2-service by a carrier? ... the possibilites are endless).

The router and the given module's systems then ensure that every system within the module gets predictable IPv6 addresses.

1. Either by being a stateful DHCPv6 server, assigning leases as <DelegatedPrefix> + <ModuleInternalSubnetID> + <predefinedHostID> (although, that might be a bit of a challenge on its own there, attempting to set up a stateful DHCPv6 service based on a DHCPv6-PD delegated network prefix with just the HostID part being preconfigured/fixed)
2. Or by implementing something like Linux's ip token on the end systems, where the end system does SLAAC to learn the current subnet prefix, but then tries it's own manually predefined HostID, performs DAD with that and brings up the IPv6 interface.

So much for (somewhat) preditctable addresses, With IPv6, having predictable addresses does not offer too much added value - it's still a bunch of Hex digits no one can remember. Enter DNS.

Some DNS magic might be advisable. Once the central DHCPv6 server assigns prefix 2001:0db8:000a to router "A", it could proceed with a script that generates a set of pre-known AAAA records like <oneOfTheKnownEndSystemNames>.moduleA.internal.myscadanet.tld, with each a ressource record of 2001:0db8:000a:<ModuleInternalSubnetID>:<givenHostID>. That's probably best done with DDNS (research topic: Dynamic DNS updates, not the DynDNS style HTTP update thing). That script may reside on the DHCPv6 server itself, which would in turn be the only system allowed to dynamically update the neighboring DNS server.

Hm. A bit on the progressive side, all of this. But still - this is the 2010's. IPv6 is a thing. Talk to your vendors.

I would consider a network design that brings along overlapping addressing by design harmful. Avoid it like the plague. In new/fresh designs, avoid NAT. Imagine the pain when you discover that one of the applications does not cope well with NAT and/or port forwarding.

I would suggest (and now this is getting opinionated, hence possibly off-topic)

Use some features only IPv6 can offer, and go IPv6-only for a modern network.

• each module gets an IPv6 capable router as entry/exit point towards the common network.
• towards the module, the router exposes as many VLANs/subinterfaces/subnets as needed, to accomplish the inta-module split of business/data/control "zones". Some rough-hewn access-lists or a firewall (e.g. ZBFW, if it's a Cisco) ensure that traffic cannot be forwarded between zones, but only to/from the central network (or the respective "zones" thereof).
• the router acts as DHCPv6-PD (prefix delegation) client towards a DHCPv6 server in the common network, requesting the delegation of a suitably sized IPv6 prefix.
• using appropriate mechanisms (i.e. a dynamic routing protocol), the central network then ensures that routing information for the freshly delegated prefix is disseminated appropriately (i.e. all routers participating in the common network eventually know that prefix 2001:0db8:000a::/48 is now reachable via router "A" and they know how to reach router "A" .) There are many different ways to accomplish this, all depending on how the common network is built (a flat LAN? a somehow emulated/stretched broadcast domain instead of a LAN ? PPPoE Sessions to a number of concentrators? a bunch of serial lines with PPP? an MPLS L3-VPN? Some MetroEthernet L2-service by a carrier? ... the possibilites are endless).

The router and the given module's systems then ensure that every system within the module gets predictable IPv6 addresses.

1. Either by being a stateful DHCPv6 server, assigning leases as + (although, that might be a bit of a topic there, configuring a stateful DHCPv6 server with a DHCPv6-PD delegated network prefix and just the HostID part being preconfigured/fixed)
2. or by implementing something like Linux's ip token on the end systems, where the end system does SLAAC to learn the current subnet prefix, but then tries it's own manually predefined HostID, performs DAD with that and brings up the IPv6 interface.

But that should stop there - and this is now leaving the scope of networkengineering somewhat...

Some DNS magic might be required. Once the central DHCPv6 server assigns prefix 2001:0db8:000a to router "A", it could proceed with a script that generates a set of pre-known AAAA records like <oneOfTheKnownEndSystemNames>.moduleA.internal.myscadanet.tld, with each a ressource record of 2001:0db8:000a:<moduleInternalSubnetid>:<givenHostID>; that's probably best done with DDNS (research topic: Dynamic DNS updates, not the DynDNS style HTTP update thing). That script may reside on the DHCPv6 server itself, which would in turn be the only system allowed to DDNS-update the neighboring DNS server.

Hm. A bit on the progressive side, all of this. But still - this is the 2010's. IPv6 is a thing. Talk to your vendors.

I would consider a network design that brings along overlapping addressing by design harmful. Avoid it like the plague. In new/fresh designs, avoid NAT. Imagine the pain when you discover that one of the applications does not cope well with NAT and/or port forwarding.

I would suggest (and now this is getting opinionated, hence possibly off-topic)

Use some features only IPv6 can offer, and go IPv6-only for a modern network.

• each module gets an IPv6 capable router as entry/exit point towards the common network.
• towards the module, the router exposes as many VLANs/subinterfaces/subnets as needed, to accomplish the inta-module split of business/data/control "zones". Some rough-hewn access-lists or a firewall (e.g. ZBFW, if it's a Cisco) ensure that traffic cannot be forwarded between zones, but only to/from the central network (or the respective "zones" thereof).
• the router acts as DHCPv6-PD (prefix delegation) client towards a DHCPv6 server in the common network, requesting the delegation of a suitably sized IPv6 prefix.
• using appropriate mechanisms (i.e. a dynamic routing protocol), the central network then ensures that routing information for the freshly delegated prefix is disseminated appropriately (i.e. all routers participating in the common network eventually know that prefix 2001:0db8:000a::/48 is now reachable via router "A" and they know how to reach router "A" .) There are many different ways to accomplish this, all depending on how the common network is built (a flat LAN? a somehow emulated/stretched broadcast domain instead of a LAN ? PPPoE Sessions to a number of concentrators? a bunch of serial lines with PPP? an MPLS L3-VPN? Some MetroEthernet L2-service by a carrier? ... the possibilites are endless).

The router and the given module's systems then ensure that every system within the module gets predictable IPv6 addresses.

1. Either by being a stateful DHCPv6 server, assigning leases as <DelegatedPrefix> + <predefinedHostID> (although, that might be a bit of a challenge on its own there, attempting to set up a stateful DHCPv6 service based on a DHCPv6-PD delegated network prefix with just the HostID part being preconfigured/fixed)
2. Or by implementing something like Linux's ip token on the end systems, where the end system does SLAAC to learn the current subnet prefix, but then tries it's own manually predefined HostID, performs DAD with that and brings up the IPv6 interface.

So much for (somewhat) preditctable addresses, With IPv6, having predictable addresses does not offer too much added value - it's still a bunch of Hex digits no one can remember. Enter DNS.

Some DNS magic might be advisable. Once the central DHCPv6 server assigns prefix 2001:0db8:000a to router "A", it could proceed with a script that generates a set of pre-known AAAA records like <oneOfTheKnownEndSystemNames>.moduleA.internal.myscadanet.tld, with each a ressource record of 2001:0db8:000a:<ModuleInternalPrefix>:<givenHostID>. That's probably best done with DDNS (research topic: Dynamic DNS updates, not the DynDNS style HTTP update thing). That script may reside on the DHCPv6 server itself, which would in turn be the only system allowed to dynamically update the neighboring DNS server.

Hm. A bit on the progressive side, all of this. But still - this is the 2010's. IPv6 is a thing. Talk to your vendors.

One might think along these lines:

Use some features only IPv6 can offer, and go IPv6-only for this modern network.

• each module gets an IPv6 capable router as entry/exit point towards the central network.
• towards the module, the router exposes as many VLANs/subinterfaces/subnets as needed, to accomplish the inta-module split of business/data/control "zones". Some rough-hewn access-lists or a Firewall (ZBFW, if it's a Cisco) ensure that traffic cannot be forwarded between zones.
• the router acts as DHCPv6-PD (prefix delegation) client towards a DHCPv6 server in the central network, requesting the delegation of a suitably sized IPv6 prefix.
• using appropriate mechanisms (i.e. a dynamic routing protocol), the central network then ensures that routing information for the freshly delegated prefix is disseminated appropriately (i.e. the router at module "A" anncounces to the central network that prefix 2001:0db8:000a::/48 is now reachable via himself. Many varieties on how to do this exist.)

The router and its end systems then ensure that every system in the module gets predictable IPv6 addresses.

1. Either by being a stateful DHCPv6 server, assigning leases as + (although, that might be a bit of a topic there, configuring a stateful DHCPv6 server with a dynamic network prefix and only the HostID part being preconfigured/fixed)
2. or by implementing something like Linux's ip token on the end systems, where the end system does SLAAC to learn the current subnet prefix, but then tries it's own manually predefined HostID, performs DAD with that and brings up the IPv6 interface.

And then, some DNS magic might help. Once the central DHCPv6 server assigns prefix 2001:0db8:000a to router "A", it will proceed with a script that generates (research topic: the true Dynamic DNS updates, not the DynDNS style HTTP update thing) a set of pre-known AAAA records like <oneOfTheKnownEndSystemNames>.moduleA.internal.myscadanet.tld, with each a ressource record of 2001:0db8:000a:<moduleInternalSubnetid>:<givenHostID>. That script may reside on the DHCPv6 server itself, which would be the only one allowed to DDNS-update the neighboring DNS server.

Hm. A bit on the progressive side, all of this. But still - this is the 2010's. IPv6 is a thing. Talk to your vendors.

I would consider a network design that brings along overlapping addressing by design harmful. Avoid it like the plague. In new/fresh designs, avoid NAT. Imagine the pain when you discover that one of the applications does not cope well with NAT and/or port forwarding.

I would suggest (and now this is getting opinionated, hence possibly off-topic)

Use some features only IPv6 can offer, and go IPv6-only for a modern network.

• each module gets an IPv6 capable router as entry/exit point towards the common network.
• towards the module, the router exposes as many VLANs/subinterfaces/subnets as needed, to accomplish the inta-module split of business/data/control "zones". Some rough-hewn access-lists or a firewall (e.g. ZBFW, if it's a Cisco) ensure that traffic cannot be forwarded between zones, but only to/from the central network (or the respective "zones" thereof).
• the router acts as DHCPv6-PD (prefix delegation) client towards a DHCPv6 server in the common network, requesting the delegation of a suitably sized IPv6 prefix.
• using appropriate mechanisms (i.e. a dynamic routing protocol), the central network then ensures that routing information for the freshly delegated prefix is disseminated appropriately (i.e. all routers participating in the common network eventually know that prefix 2001:0db8:000a::/48 is now reachable via router "A" and they know how to reach router "A" .) There are many different ways to accomplish this, all depending on how the common network is built (a flat LAN? a somehow emulated/stretched broadcast domain instead of a LAN ? PPPoE Sessions to a number of concentrators? a bunch of serial lines with PPP? an MPLS L3-VPN? Some MetroEthernet L2-service by a carrier? ... the possibilites are endless).

The router and the given module's systems then ensure that every system within the module gets predictable IPv6 addresses.

1. Either by being a stateful DHCPv6 server, assigning leases as + (although, that might be a bit of a topic there, configuring a stateful DHCPv6 server with a DHCPv6-PD delegated network prefix and just the HostID part being preconfigured/fixed)
2. or by implementing something like Linux's ip token on the end systems, where the end system does SLAAC to learn the current subnet prefix, but then tries it's own manually predefined HostID, performs DAD with that and brings up the IPv6 interface.

But that should stop there - and this is now leaving the scope of networkengineering somewhat...

Some DNS magic might be required. Once the central DHCPv6 server assigns prefix 2001:0db8:000a to router "A", it could proceed with a script that generates a set of pre-known AAAA records like <oneOfTheKnownEndSystemNames>.moduleA.internal.myscadanet.tld, with each a ressource record of 2001:0db8:000a:<moduleInternalSubnetid>:<givenHostID>; that's probably best done with DDNS (research topic: Dynamic DNS updates, not the DynDNS style HTTP update thing). That script may reside on the DHCPv6 server itself, which would in turn be the only system allowed to DDNS-update the neighboring DNS server.

Hm. A bit on the progressive side, all of this. But still - this is the 2010's. IPv6 is a thing. Talk to your vendors.