Subnet calculator for IPv4 and IPv6

Scenario

You are defining the corporate address space from scratch. There are 150 sites and 16 plants, and the cloud virtual networks go in the same space. Business units are reorganized every few years, and the regions that sites belong to change too. You are at the stage of deciding, first of all, what goes where in 10/8.

Assumptions

You can carve up 10/8 freely within your own company. For now, you do not need to consider that a future integration might mix this space with another company's. More kinds of purpose can be added later. You can count the filter lines that reference the boundaries.

Allocation

Reasoning

The first thing to decide in 10/8 is what the second octet means. There are three candidates: split by purpose, by organization, or by geography.

In short, split by purpose. Organizations and geography change, but purposes do not. Business units are reorganized every few years, and regional responsibilities get reshuffled. By contrast, a plant never turns into an office site, and a test environment never becomes production.

If you split by organization, every reorganization forces a choice: move the boundaries, or leave names that no longer match reality. The latter is almost always chosen, and a few years later a different department is sitting in the sales block. At that point, the divisions in the design document and what is actually on the devices no longer agree.

The top-level boundaries cannot be moved, because filters are written on the assumption that 10.16.0.0/12 is the plants. If a boundary moves, every line that references it has to be reviewed. With 150 sites, 16 plants, and the cloud, that means hundreds of lines, and unless they are all switched at once, there will be a window in which traffic passes in only one direction.

So keep what you decide up front to a minimum. Splitting 10/8 on /12 gives 16 blocks to hand out to purposes. Start with four purposes, and add one block when you run out. Blocks are only ever added, so existing boundaries never move. Using only 4 of 16 blocks looks wasteful, but not having to move anything is worth more.

Room to grow

There are 16 /12 blocks. The four purposes (enterprise-wide shared, sites, plants, and cloud) use four blocks, leaving twelve free. When adding a purpose, hand it a free block such as 10.64.0.0/12 and leave existing boundaries alone. Purposes that appear later, such as testing or IoT, also take a new block rather than splitting an existing one. Which block to hand out next is decided when it is needed.

Pitfalls

• Splitting the second octet by organization. Organizations are reorganized every few years but boundaries cannot move, so names drift away from reality and stay that way. Split by purpose instead.
• Defining many fine-grained purposes from the start. Not only do unused blocks pile up, but every new request needs a decision about which purpose it belongs to. Start with about four and add more when needed.
• Borrowing part of a neighboring block for a purpose that has run out. A boundary appears in the middle of the block, and from then on that block alone mixes two purposes. If a purpose runs out, hand it a whole block.
• Recording only the result of the split, not the reasons. The next person can read which block is for what, but not why the split is by purpose, so proposals to re-split by organization keep coming up.
• Taking the enterprise-wide shared range last. The convenient blocks get handed out first, and enterprise-wide shared ends up scattered across distant blocks. Give enterprise-wide shared the first block.

Scenario

A company of about 100 people keeps its field equipment and test devices in the 192.168 range. Whenever a site-to-site connection with a business partner or contractor comes up, the addresses conflict with the other party's premises and have to be sorted out. Remote-work connections sometimes conflict with employees' own wireless routers as well.

Assumptions

The addresses used on the other party's premises cannot always be learned in advance. Devices that are routed to the outside can be separated from those that are not. Changing a device's address later requires an on-site visit and reconfiguration. 10/8 is also available for use.

Allocation

Reasoning

192.168.0.0/16 is not yours alone. Home devices, employees' own wireless routers, and the premises of partners and contractors all use the same space. It is well known that defaults cluster on 192.168.0 and 192.168.1, but the problem does not stop there. Small devices also default to 192.168.10, 192.168.100, and others, and you usually cannot find out in advance what the other party uses.

If you work around each block that conflicts, the record of avoided blocks keeps growing. After ten years of operation it runs to dozens of blocks, and every new partner has to be checked against the list. People do the checking, so things get missed.

So turn it around. Fix the range you use by its high-order bit, and claim only the half where the third octet is 128 or above. You give up half the space, but the decision is made once. A company of about 100 people needs fewer than 10 blocks, so 128 is more than enough.

Also limit what goes there. The only things allowed in this space are those that are not routed to other companies or other sites. If you know that conflicts in this space cannot be avoided, put only things there that do not suffer when a conflict happens. Anything visible from the far end of a site-to-site connection, or exposed to an interconnection, takes addresses from 10.0.0.0/8.

Room to grow

The company uses only the half where the third octet is 128 or above, and uses 4 of those 128 blocks. The other half, 192.168.0.0/17, stays empty, and no block-by-block checking is done even as partners increase. The decision is a single check: is the third octet 128 or above? When something needs to be routed to the outside, it does not go in this space; it takes addresses from 10.0.0.0/8. Even as devices increase, the half in use is enough.

Pitfalls

• Carving on the assumption that all of 192.168 belongs to you. Every interconnection brings a conflict, each one is handled by avoiding a block, and the records of avoided blocks end up scattered. Fix the range you use by its high-order bit.
• Keeping a list of conflicting blocks to avoid. Every new partner requires a check against it, and because people do the checking, things get missed. Make the decision a single check of the high-order bit.
• Putting devices that are visible from outside in this space. When they conflict with the other party's premises, only your side can move, so you end up changing the devices' addresses. Take addresses for anything exposed to the outside from 10.0.0.0/8.
• Starting to use the unused half because leaving it empty feels wasteful. Blocks you start using cannot be taken back; you gain nothing and lose the simplicity of the decision. For about 100 people, 128 blocks are more than enough.

Scenario

A head office or branch office with around 100 employees on one or two floors. It uses both wired and wireless, and keeps a file server and a NAS on premises. This is the most typical setup.

Assumptions

At least one Layer 3 switch or VLAN-capable router is in place. DHCP can run either on a network device or on a server. Headcount may grow to 1.5 times its current size within three years.

Allocation

Reasoning

At around 100 people, the first question is whether a single /24 is enough. The answer: for wired alone it is, but the site must not be cut as a single /24 block. Wired clients alone fit in a /24 block. Once company smartphones and the wireless connections of laptops are counted, however, each person actually has two or three devices, and the 254 addresses of a /24 fill up quickly.

So reserve a /22 and cut it internally into /24 and /26 blocks. Wired clients and wireless each get their own /24 so that exhaustion of one DHCP pool does not spill over into the other. Servers and management stay at /26 because at this scale they rarely exceed 60 devices, and allocating more would cost the readability of the third octet.

Giving the third octet a meaning is also deliberate. With 0 = wired, 1 = static-IP devices, 2 = wireless and 3 = phase 2, a glance at a packet capture or a log tells you which segment an address belongs to. This readability translates directly into faster troubleshooting.

Room to grow

Because 10.20.3.0/24 is left entirely free, even if headcount grows 1.5 times you can either widen wireless to a /23 or add one departmental segment. If the servers' /26 gets tight, move the printers in 10.20.1.128/27 over to 10.20.1.192/27, then move device management into the freed 10.20.1.128/26; the servers can then double to 10.20.1.0/25. To add another site, continue with 10.21.0.0/22, 10.22.0.0/22 and so on, and aggregate them as 10.20.0.0/14.

Pitfalls

• Using 192.168.1.0/24 or 192.168.0.0/24 on the corporate network. These conflict with the defaults of home routers, so routing breaks when people connect over VPN from home. Carve from 10/8 instead.
• Putting wireless and wired clients in the same segment. When you later want to add a guest SSID, the addressing plan has to be redone. Separating them from the start costs almost nothing.
• Mixing the management addresses of network devices into a client segment. ACLs can no longer restrict management access on its own, and audits will always flag it.
• Using the spare /24 for an immediate need “because it is free.” A spare is valuable precisely because it stays unused. Name it “phase 2” rather than “spare”; it is then more likely to be respected.

Scenario

A site of about 100 seats with no assigned desks. Against a headcount of 120, office attendance swings between 40% and 80% from day to day. Everyone carries a laptop, and wired ports remain only in meeting rooms and at a few fixed desks. About 10 short-term staff, such as agency workers and on-site contractors, are present at any time.

Assumptions

Wireless covers the whole site, and employees can do all their work on their devices over wireless alone. The DHCP lease time can be set per segment. Actual daily attendance can be retrieved afterwards, for example from entry and exit records. No desk booking system is in place.

Allocation

Reasoning

When sizing the pool, the first numbers that come up are the 100 seats and the headcount of 120. Drop the seat count first. Next comes the number of devices at peak attendance: at 80% attendance that is 96 people, and since each carries a laptop and a company smartphone, 192 devices. Up to this point, the 254 addresses of a /24 are enough.

This is where the estimate goes wrong. With hot desking, nobody knows who will come in today. With a 24-hour lease time, the addresses of devices belonging to people who came yesterday but not today are still alive. Attendance swinging between 40% and 80% means there are days when few of the same people come in two days in a row. If a 40% day (48 people) is followed by an 80% day (96 people) with almost no one in common, the number of people who came over the two days approaches the headcount of 120, and live leases reach up to 240 devices. That is 94% of the 254 addresses in a /24, leaving only 14. Exhaustion does not come on the most crowded day; it comes on the day the people change. What must be counted is not peak attendance but the number of people who could come within one lease time, in other words a number close to the headcount.

Could the lease simply be shortened? There is a lower limit. Laptops closed over lunch and afternoon meetings go silent for three to four hours, so with a 2-hour lease some devices pick up a different address when they come back. The pool size sets the upper limit on the lease time, and the way people work sets the lower limit. The only way to satisfy both is a /23 for the pool. With 510 addresses, 53% remain free even at 240 devices.

Taking a /23 breaks the match between the third octet and the segment, but at this site avoiding exhaustion takes priority over readability. Devices that communicate while constantly on the move need a separate decision if they are to share the same pool.

Room to grow

The adjacent 10.16.10.0/23 is kept free not for some future need but so that the pool can grow as a single subnet. A pool cannot be extended by adding separate pieces, so turning the /23 into a /22 requires the entire adjacent /23 to be free. The trigger is set at a headcount of 210 because if almost everyone comes in over two days, that means 420 devices, 82% of the 510 addresses in the current /23 block. At that point, merge the adjacent block to form 10.16.8.0/22 and leave the lease time as it is. This constraint is why wired and servers have been pushed out to 10.16.12.0/24. Unless the conditions for releasing the free space are decided in advance, it will always be taken for some other use.

Pitfalls

• Sizing the pool by seat count. If a /25 is cut because there are 100 seats, it falls short as soon as two devices per person and the short-term staff are counted, and the pool runs out in the first week of operation. Count devices, not seats.
• Shortening the lease time to speed up turnover and avoid exhaustion. Devices coming back after lunch or a meeting pick up a different address and lose their connections, but since the drop happens only at the moment they come back, it cannot be reproduced and never gets reported.
• Putting short-term staff devices in the same pool as employees. The device count estimated from headcount keeps drifting from reality, and with each increase in staff nobody can explain how many addresses were short. Keep what can be predicted apart from what cannot.
• Keeping the practice of assigning static IPs to wired ports. With hot desking, a different person sits at the same port every day, so the mapping between addresses and users soon breaks down and only the address register remains. Serve wired ports by DHCP as well.

Scenario

150 sites in total: 1 head office, 8 regional hubs, and 141 sales offices and warehouses. Each site connects to the head office through a regional hub, and routes are aggregated at the regional hubs and passed upstream. Site numbers are already used in asset management and in forms and reports, and were assigned in order of opening. A few sites open and a few close every year.

Assumptions

Each regional hub can advertise the sites under it as a single route. A site numbering scheme already exists, and sites cannot be renumbered for the sake of the addressing plan. No site has more than 1,000 devices. Which region each site belongs to stays the same for years at a time.

Allocation

Reasoning

Aggregation is what keeps 150 sites from going upstream as 150 routes. But what aggregation needs is contiguous address blocks, not contiguous site numbers. Get this wrong and the whole design is wasted.

The site numbers already exist. They are used in asset management and in forms and reports, were assigned in order of opening, and have no relation to regions. Map them straight onto the second octet and the hub for region 3 ends up holding a scattered set such as sites 3, 17, 42 and 88. Scattered blocks do not combine into one route, so 150 routes still go upstream. Renumbering for aggregation is not an option: the numbers are embedded in forms, reports and the names people use.

So reverse the order. Assign blocks first to the unit of aggregation, the regional hub, and hand out site numbers as identifiers inside that block. Each of the 8 regions gets one second octet, and each site gets one /22 block. A region holds up to 64 sites. With 150 sites even the largest region has only 24, so everything fits, and 8 routes go upstream. Even if the sites double to 300, it stays at 8.

The cost is that the site number can no longer be read from the address. Making it readable means giving up contiguity within regions. What incident response needs is not a numbering rule but one table that maps site numbers to blocks.

Room to grow

Regional blocks use second octets 1 to 8, and 0 is used for enterprise-wide shared purposes. The seven blocks 9 to 15 are kept free, for adding regions and for a second regional block given to any region that exceeds 64 sites. Those numbers are not contiguous, so look them up in the mapping table. Everything from 10.16.0.0/12 upward is left untouched and kept for acquisitions and for taking in other businesses.

Pitfalls

• Mapping site numbers directly to addresses. The numbers follow the order of opening and have nothing to do with regions, so the sites under one hub end up scattered and as many routes as there are sites still go upstream. Hand out numbers inside the regional block.
• Taking inter-site link addresses from the site's own block. When the other end is a site in another region, addresses from this region's block end up in that region, and more specific routes for them go upstream. Take links from a shared block outside the site blocks.
• Adding segments inside a site across the boundary of the site block. The part that spills over is not covered by the aggregate, and a more specific route for that one site goes upstream. Add only inside the block, and give a second block once it is exceeded.
• Requiring that the site number can be read from the address. Making it readable means giving up contiguity within regions, and aggregation stops working. Keep a mapping table instead of a numbering rule.
• Homing a single site on a different regional hub for geographic convenience. Its addresses stay in the original regional block, so upstream sees the regional block alongside a separate route for that one site. If a site's hub changes, move its addresses with it.

Scenario

In a network with 300 or more point-to-point links, you need to settle the prefix length for links. The devices span several generations: older equipment, special-purpose appliances, and virtual devices sit side by side. Standardizing on /31 has been proposed as a way to save addresses.

Assumptions

The model and generation of the devices at both ends of each link can be listed. Whether a device handles /31 can be checked in advance. Allocation is done in one place. Changing a link's addresses later requires rewriting device configurations and monitoring.

Allocation

Reasoning

A /30 has four addresses, only two of them usable; a /31 uses both of its two. The number of addresses needed is halved.

As a saving, though, this means nothing. With 352 links, /30 takes 1,408 addresses and /31 takes 704. The difference of 704 is only about 1 percent of the /16 block set aside for links. A difference that small is no reason to change the decision.

The deciding factor is whether every device can handle it. Not every device supports /31 links. Older equipment, special-purpose appliances, or virtual devices may lack support. A link has one device at each end, so if even one of them lacks support, that link has to be a /30 link anyway.

Mixing the two changes the allocation procedure. The pool then holds two sizes, and every allocation requires checking support on the devices at both ends. At 10 links a month, that is 120 checks a year. Saving 704 addresses is not worth 120 checks a year.

So standardize. If every device supports it, use /31; if even one device without support remains, use /30 for every link. If mixing is unavoidable, split the sizes into separate ranges so that no check is needed at each allocation.

One more point. A link once cut as a /30 does not move to /31 even when its devices are replaced. Moving it means changing its addresses, which rewrites configurations and monitoring names. Do not plan on a later migration.

Room to grow

The default is /30, and only sections with confirmed support are cut from the /31 range. The ranges are split so that allocation never requires checking device support. A section is added to the /31 range only when the devices at both ends have been replaced and their support confirmed. Growth comes from 10.161.16.0/21. Even after every device has been replaced, existing /30 links are not converted; only newly created links are cut as /31 links.

Pitfalls

• Choosing /31 to save addresses. The saving is about 1 percent of the link block and no reason to change the decision. Base the decision on whether every device supports it.
• Mixing both sizes in the same range. Every allocation then needs a support check on the devices at both ends, adding 120 checks a year at 10 links a month. If you must mix, use separate ranges.
• Making /31 the default while one device still lacks support, with only that section kept as a /30 exception. Every device replacement then needs a support check, and missing it even once leaves that link unusable. Make /30 the default, and cut /31 links only from the range for sections with confirmed support.
• Choosing /30 on the assumption of moving to /31 later. Moving means changing addresses, which rewrites configurations and monitoring names. Decide on the assumption that links will never move.

Scenario

A company of about 100 people is setting up guest wireless. On normal days there are about 20 guest devices, but on days with information sessions or exhibitions, 400 arrive at once. Traffic to the corporate network is blocked by filters, but name resolution and address assignment run on the same equipment as the corporate network.

Assumptions

Guest wireless can be offered as a range separate from corporate wireless. A single outbound exit can be provided for guests. Separate name resolution and address assignment equipment can be set up for guests. There is a usable position within 172.16/12.

Allocation

Reasoning

The usual assumption is that guest wireless only needs to be cut off from the corporate network: block traffic to the corporate network with filters and the job is done. That is not enough.

The guest range also shares things with the corporate network outside the filters. If guests resolve names through corporate equipment, guest devices can query the names of corporate servers. Even when no answer comes back, the response to a query shows which names exist. If addresses are assigned by the same equipment as the corporate network, then on an event day when 400 devices come to a 100-person company, corporate address assignment chokes as well. If guests are made to sync their clocks to the corporate network, a route to the corporate time server has to be opened.

So the guest range shares nothing with the corporate network. It has no route to any corporate segment, and its only exit is a single outbound one. Name resolution and address assignment are kept separately, for guests alone. Instead of blocking with filters, the routes that would need blocking are made not to exist at all. A blocked route can be opened with one line; a route that does not exist cannot be opened.

The choice of addresses has a reason too. Most guest devices open connections back to their own company. If that company uses 10/8 internally and the guest range is also in 10/8, addresses collide on the other side and the guest cannot reach their own company. The range is taken from a little-used position within 172.16/12.

Room to grow

The guest range has no route anywhere in the corporate network, and its only exit is a single outbound one. Name resolution and address assignment are also kept separately for guests. When events bring more devices, 172.30.4.0/22 is added to take them, and the added range leaves through the same exit. No routes to the corporate network are added. The range stays within 172.16/12 and does not overlap 10/8, which guests' companies are likely to use.

Pitfalls

• Relying on filters to stop traffic to the corporate network. If name resolution or address assignment is shared with the corporate network, internal information leaks outside the filters and load carries over too. Share nothing.
• Letting guest devices use corporate name resolution. Even without answers, the responses to queries show which names exist. Keep separate name resolution for guests.
• Running guest address assignment on the same equipment as the corporate network. When guests surge on an event day, corporate address assignment chokes too. Separate address assignment for guests.
• Taking the guest range from 10/8. When guests connect back to their own company, addresses collide with that company's internal network and the connection fails. Take it from a little-used position within 172.16/12.

Scenario

At a company of about 500 people, the equipment placed in the DMZ grows every year. A public-facing web server, a server for exchanging files with business partners, equipment that receives mail from outside, a server that only calls external services, and equipment that sends monitoring alerts out all share one range.

Assumptions

Equipment that receives connections initiated from outside can be told apart from equipment that only sends traffic out. The counterparts of each business partner connection can be identified. DMZ ranges can be provided separately per counterpart. Traffic between ranges can be stopped at the boundary.

Allocation

Reasoning

There is one criterion for what goes in the DMZ: equipment that receives connections initiated from outside.

Without a criterion, everything that talks to the outside ends up there: equipment that only sends traffic out from inside, servers that only call external services, equipment that sends monitoring alerts out. None of these receive connections initiated from outside, so there is no reason to place them in the DMZ. Placing them there makes the DMZ grow, and when any one of them is compromised, everything next to it becomes reachable.

Once what goes in is decided, the next split is by who it receives from. Public-facing and partner-facing equipment do not share a range. Anyone can reach the public-facing side, so it is designed on the assumption that it will be compromised. The partner-facing side has known counterparts, so its permissions are far narrower. If the two share a range, a compromised public-facing server can reach the files exchanged with partners from right next door. Restricting the counterparts then means nothing.

Traffic between the separated ranges is not allowed. There is not a single business reason for the public-facing side to reach the partner-facing side.

When new equipment that receives from outside appears and it is unclear who it receives from, it goes into the public-facing range. Putting equipment whose counterparts cannot be restricted into the partner-facing range breaks the premise of that range.

Room to grow

The DMZ is split by who each range receives from, with public-facing and partner-facing equipment in separate ranges. Traffic between ranges is not allowed. When new equipment that receives from outside appears, its range is decided by who it receives from, and if that cannot be decided, it goes into the public-facing range. When ranges run short, they are cut from 10.170.1.0/24. Equipment that only sends traffic out stays out of the DMZ no matter how much of it there is.

Pitfalls

• Putting everything that talks to the outside into the DMZ. Once equipment that only sends traffic out goes in too, the DMZ grows, and one compromise reaches everything next to it. Place only equipment that receives connections initiated from outside.
• Putting public-facing and partner-facing equipment in the same range. When the public-facing side is compromised, the files exchanged with partners can be reached from next door. Split ranges by who they receive from.
• Allowing traffic between the separated ranges just in case. A permission with no business reason only becomes a path for an intruder. Allow nothing between ranges.
• Putting equipment with unclear counterparts in the partner-facing range. That range keeps its permissions narrow on the premise that its counterparts are known, and the premise breaks. When in doubt, use the public-facing range.

Scenario

You are creating a small subnet for 10 devices in each failure zone of a cloud virtual network. Thinking as you would on the corporate network, you expect a /28 to hold 14 devices. An application subnet of about 200 hosts is also planned for the same virtual network.

Assumptions

You know that your provider takes some addresses inside each subnet in advance. You can check how many it takes and the smallest subnet size it allows. A subnet's size cannot be changed after it is created. The virtual network has free space.

Allocation

Reasoning

When you create a subnet in the cloud, the provider takes some of its addresses in advance. It varies by provider, but taking the first four and the last one, five in total, is common. On a corporate network only the first and last addresses are unusable, so carving subnets without knowing this difference leaves you short.

The difference hits small subnets hardest. In a /24 it is 5 of 256, under 2 percent. In a /26 it is 5 of 64, or 8 percent. In a /28, the smallest size you can create, 5 of 16 disappear, roughly 30 percent. Only 11 are usable.

Carve a /28 with corporate-network habits and you expect room for 14 hosts but can place only 11. With 10 devices, the margin is a single address, and the day you add two more, the subnet overflows. A subnet's size cannot be changed after creation, so an overflow means rebuilding it.

So when carving small subnets, compare the host count with the number left after reservations. For 10 hosts, take a /27 rather than a /28 subnet. A /27 leaves 27 usable after subtracting 5 from 32. The smaller the subnet, the larger the share lost, so as a rule small subnets are carved one size larger than on the corporate network.

The number of reserved addresses differs by provider, and so does the smallest size allowed. Choose a reservation profile in the Calculate tab and the usable count appears immediately. Check your estimates there.

Room to grow

For small subnets, subtract the 5 reserved addresses before comparing with the host count. For 10 hosts, take a /27 rather than a /28 subnet. Line them up at the same size, one per failure zone. When more subnets are needed, carve them from 10.216.2.0/24. If you are unsure about an estimate, choose the reservation profile in the Calculate tab and check the usable count.

Pitfalls

• Counting usable addresses with corporate-network habits. Subtracting only the first and last overlooks the other three the provider takes, and the planned number of hosts does not fit. Compare using the count after reservations.
• Making the smallest size, /28, the standard. Five of 16 disappear, leaving only 11 usable, and adding just a few hosts overflows it. For about 10 hosts, take a /27 subnet.
• Assuming a subnet can be enlarged later. Its size cannot change after creation, and an overflow means rebuilding it. Estimate with reservations included from the start.
• Assuming every provider reserves the same number. Providers differ both in how many addresses they take and in the smallest size allowed. Check with the profile for your provider.

Scenario

You are connecting the network of a company you acquired to your own. Both use 10/8, and many ranges overlap. Business needs require the networks to be connected by next month, and there is no time to renumber either side. A proposal is on the table to connect them by translating addresses at the boundary.

Assumptions

One boundary that can translate addresses can be placed between the two companies' networks. Translated addresses can be taken from space outside both companies' address spaces. A deadline can be written into the translation rules. The side to renumber can be decided without waiting for a management decision.

Allocation

Reasoning

There are two ways to connect two overlapping networks: renumber one of them, or translate addresses at the boundary. Translation can be in place overnight; renumbering takes months. Choosing translation early in an integration is right.

The problem is that translation becomes permanent. Because traffic gets through with translation in place, the reason to renumber disappears. Three years later, translation rules have piled up and no one can explain them as a whole. At every incident, someone has to check whether an address in the logs is from before or after translation.

So on the day translation goes in, decide two things together: the deadline, and the side that will be renumbered. Set the deadline as a date and write it into the translation rules themselves. Decide the side to renumber that same day, and treat the translation period as preparation time for the renumbering. A translation with no decision on which side to renumber can only be extended when the deadline arrives.

Take the translated addresses from space that belongs to neither side. If both you and the other company use 10/8 and that is where the overlap is, take the translated addresses from 172.16/12. If you use free space in either side's 10/8, the next company you take in will overlap again.

Some translation can be permanent. When identical addresses repeating side by side is a premise of the design, as with production lines built from the same copied configuration, permanent translation is correct. An overlap in an integration is not a premise but an accident, and the remedy for an accident must not be made permanent.

Room to grow

Take the translated ranges within 172.16/12, and keep the range for seeing the other company's network separate from the range that presents your network to the other company. Write the deadline into the translation rules, and by the deadline renumber the side decided on the day translation went in. Carve any growth until the deadline from 172.18.24.0/22. Do not extend a translation past its deadline; if an extension is needed, start again from the decision on which side to renumber.

Pitfalls

• Not setting a deadline when translation goes in. Traffic gets through, so the reason to renumber disappears, and translation rules pile up until no one can explain them.
• Putting translation in without deciding which side to renumber. When the deadline comes, the discussion starts over from which side to move, so the only option is to extend. Decide on the same day as the translation.
• Taking translated addresses from free space in your own 10/8. The next time you take in another company, they will overlap again. Take them from space that belongs to neither side.
• Writing translation rules one host at a time. Deadlines then have to be managed one host at a time too, and no one knows which rules remain. Write them per range.

Scenario

A plant has several production lines with the same equipment configuration and plans to add more. The controllers delivered by the equipment vendor have fixed IP addresses burned in, and you start from a state where the same addresses overlap between lines.

Assumptions

The controllers' addresses on each line cannot be changed, or changing them requires the equipment vendor to repeat acceptance testing. Lines do not need to talk to each other directly; they only need to talk to the upstream collection systems. A Layer 3 device or a device capable of NAT can be placed at each line boundary.

Allocation

Reasoning

What sets OT networks decisively apart from IT is that addresses cannot be chosen freely. Equipment vendors deliver the same configuration to many customers, so controller addresses are fixed at shipment, and the same 192.168.0.10 exists on line 2 and on line 3 alike. Apply the usual IT reflex, "it overlaps, so renumber it," and the discussion turns to equipment warranties and repeated acceptance testing while the floor stands still.

So do not renumber. Leave the addresses inside each line as the equipment vendor set them, apply 1:1 address translation on the device at the line boundary, and distinguish only the addresses seen from outside, by line number. A controller on line 1 appears from outside as 172.20.1.x, and the same device on line 2 as 172.20.2.x. With the rule that the third octet equals the line number, anyone reading the collection system's logs can tell the line at once without knowing device names.

The essence of this design is to separate the equipment vendor's constraints from IT manageability with a single layer: translation. Inside the line is the equipment vendor's world; from the boundary up is the IT department's world. The biggest advantage is that adding a line does not mean redoing the design: increment the number by one and copy the same configuration.

Room to grow

172.20.4.0/22 (lines 4 to 7) is reserved for the next expansions. Because the base block is a /16, the rule of using the third octet as the line number reaches line 255 (0 is not used as a line number and is set aside for shared collection and maintenance), and from line 8 on it continues naturally with 172.20.8.0/21 and 172.20.16.0/20. If more plants are added, the second octet becomes the plant number: 172.21.0.0/16 goes to the next plant, and both are aggregated as 172.20.0.0/15. A line outgrows its /24 only when it has more than 250 controllers, and at that scale the line is easier to operate if it is split logically.

Pitfalls

• Allowing traffic between lines "just in case." When one line is infected with malware, every line with the same configuration stops at once. Block traffic between lines by default and route the traffic that is needed through the collection systems.
• Providing no segment for maintenance laptops and plugging brought-in PCs straight into the control segment. This is the most common entry point for OT incidents, and it leaves no record. Create a dedicated segment and allow entry to the control side only from there.
• Keeping the address translation mapping table only in the device configuration. Once the person who set it up moves on, nobody can explain which outside address belongs to which piece of equipment. Keep the mapping table in the design documents as the primary record.
• Using the 192.168 range for plant addresses. It easily conflicts with the routers and mobile routers that maintenance vendors bring in, and the conflict only shows up on site. Carve plant addresses from 172.16/12 or 10/8 instead.
• Mapping line numbers to addresses by filling whatever number happens to be free at each expansion. When line 7 is removed and different equipment later takes its place, the numbers drift away from the physical lines and nobody trusts them. Never reuse a number.

Scenario

A plant of about 300 employees with an office building and a factory building on the same premises, run until now as a single network. Production management will still need to send instructions to the equipment and collect results from it, but office PCs must no longer be able to reach controllers directly. You are at the stage of redrawing only the boundaries above and below the lines first, without touching the design inside the lines.

Assumptions

At least one Layer 3 device can be placed between the office side and the plant side. Traffic crossing between the two sides can be listed, at least per handoff server, by peer and direction. Controller addresses are not changed this time, and the redesign inside the lines is done separately. The requirements include that production can continue while the boundary devices are down.

Allocation

Reasoning

Nobody objects to separation. What never gets decided is the size of the zone placed at the boundary.

Taking a /24 for the boundary always fails. At this scale, the only machines that truly need to talk to both sides are the handoff servers, a dozen or so. The remaining 240-plus addresses become empty lots, and empty lots always get filled. Six months later a business file server moves in; the following year, a jump server joined to the office authentication infrastructure. At that point the boundary is no longer a boundary, but nothing changes in the address table, so nobody notices.

That is why the handoff is held to a /28 and no larger. With only 14 addresses, whoever tries to place a fifteenth machine has to ask someone first. The aim is to make the size work as an operating rule. Room to grow is placed next door under a different name, for phase 2, and the handoff zone itself is never widened.

Splitting the /20 into three areas, 0 to 3 (IT), 4 to 7 (boundary), and 8 to 15 (control), is also deliberate. The boundary device's filters can be written in three lines, 10.60.0.0/22, 10.60.4.0/22, and 10.60.8.0/21, and those three lines stay the same as segments are added. With a design that touches the filters at every addition, someone will one day touch them wrongly and stop production.

The zone for the control network's shared services, a /25, sits on the control side for the sake of availability. Production continues while the boundary devices are down. If time synchronization and name resolution depend on the office side, a boundary outage becomes a control-side outage.

Room to grow

At the boundary, 10.60.4.64/26 is kept free for phase 2. It is not for widening the handoff zone but a place to add external data links and remote maintenance relays later. On the control side, 10.60.12.0/22 is kept free for per-line zones, and per-line designs go there. If the wireless outgrows its /24, add 10.60.10.0/23. If more plants are added, assign 10.60.16.0/20 to the next plant and aggregate them as 10.60.0.0/16. Because the edges of the three areas are aligned on /22 boundaries, the three filter lines take the same form at every plant.

Pitfalls

• Placing a jump server at the boundary and joining it to the office authentication infrastructure. This opens a path for credentials to flow in from the office side, and the boundary loses its meaning. If a jump server is placed there, keep its authentication closed inside the boundary.
• Leaving controllers pointed at an office-side server for time synchronization. The moment the boundary device is stopped, control-side clocks start to drift, and logs cannot be matched up when a failure is traced later. Put time synchronization on the control side.
• Defining the separation requirement only as "no entry from the office into the control network." Traffic from the control side to the office side goes unchecked, leaving a way out for a device slipped in among the equipment. Set rules for both directions.
• Having the handoff servers also do collection and file storage. The side that cannot be stopped keeps them from being updated, and within a few years nobody dares touch them. Split them by role and keep their count within the /28 limit.

Scenario

A company with 10 sites has received an IPv6 /48 from its ISP. With IPv4, it sized each subnet to its device count and paid close attention to where spare space went and to fragmentation. It is about to start allocating IPv6 with the same mindset.

Assumptions

A /48 has been received from the ISP. Devices in the company can use IPv6 automatic address configuration. The number of sites and the number of purposes are each expected to stay at 15 or fewer. Addresses are meant to be read by people, who take meaning from them.

Allocation

Reasoning

A /48 contains 65,536 /64 subnets. Much of the thinking built up over years of IPv4 is reversed here.

In IPv4, subnet size was decided by device count: a /28 for 10 devices, a /24 for 200. IPv6 does not do that. Every subnet is a /64 subnet, regardless of device count. The mechanism by which devices choose their own addresses is built on the assumption of a /64 prefix. Cut smaller than a /64, and that mechanism stops working.

No conservation is needed either. Almost no organization will use up 65,536 /64 subnets. The problems that took so much effort in IPv4, such as where to put spare space and how to prevent fragmentation, all but disappear.

One decision remains: how to divide the 16 bits of the fourth 16-bit group. Here, 4 bits go to the site, 4 bits to the purpose, and 8 bits to a sequence number. When the boundaries between meanings fall on the boundaries between hex digits, an address can be read at a glance. 2001:db8:100:1200::/64, for example, is the first server subnet at site 1.

Align the divisions with hex digits. Divide in the middle of a hex digit, and every reading of an address means converting it to binary, which throws away the benefit of readability. If the number of sites may exceed 15, give the site 8 bits from the start and 4 bits each to the purpose and the sequence number.

Room to grow

The first hex digit of the fourth 16-bit group is the site, numbered from 1, with 0 kept for company-wide use. The second digit is the purpose and the last two are the sequence number. Subnets are always /64 subnets and do not grow when devices increase. The /64 subnets in the segment table look large for their device counts because the protocol requires a /64 prefix, not because extra room was taken. If sites exceed 15, keep the divisions as they are and obtain a second /48 prefix.

Pitfalls

• Sizing subnets by device count and cutting them smaller than a /64 subnet. The mechanism by which devices choose their own addresses assumes a /64 prefix and stops working. Always use /64 subnets.
• Packing subnets tightly out of concern for spare space and fragmentation, as in IPv4. Using up 65,536 /64 subnets is almost unheard of, and packing gains nothing. Put readability first.
• Dividing the fourth 16-bit group in the middle of a hex digit. Every reading of an address means converting it to binary, and meaning can no longer be read from the address. Divide on hex digit boundaries.
• Numbering the site digit from 0. There is no place left for company-wide use, and it has to be squeezed in later. Keep 0 for company-wide use.