MAC address pool management for multiple factories

A single engineer allocating from one spreadsheet on one machine can keep MAC addresses unique by being careful. Add a second factory, a contract manufacturer, or two production lines that run at the same time, and "be careful" stops being a control. This guide is about managing a MAC address pool once more than one party draws from it.

Why spreadsheets and shared CSV files become unsafe

A shared allocation spreadsheet fails in specific, repeatable ways once it is not a single writer:

• Read-modify-write races. Two people open the file, both see "next free: 0x4000", both take it. Cloud spreadsheets narrow the window but do not close it, and an exported copy sent to a factory reopens it completely.
• Stale copies. A factory works from the CSV you emailed on Monday. You allocate more on Wednesday. Neither of you is wrong about their own copy.
• Silent reuse. A row gets deleted to "free up" a range that a scrapped build used. Months later that range is handed out again.
• No history. When a duplicate turns up in the field, the spreadsheet shows the current state, not who allocated what when, so the overlap cannot be traced.
• Formulas that generate identifiers. An =BASE() or fill-down that computes the next MAC has no idea what any other sheet has done.

Central allocation across sites

The replacement is one authority that owns the pointer. Every site requests a range from it and receives a reservation; no site computes its own next address. The authority guarantees each reservation is disjoint from every other, including reservations made at the same instant. In the tool here, that authority is the account that holds the block, and each request is a batch generation that atomically takes a contiguous MAC range plus a matching serial range.

Factory-specific subranges

Give each site its own slice of the block up front, modelled as its own portfolio (optionally its own registered sub-block). Benefits:

• An address tells you which site built the unit.
• A bookkeeping error at one site is contained to that site's slice.
• You can hand a contract manufacturer a slice that is theirs, with a hard upper bound, without exposing the rest of the block.

Concurrent production requests

Two lines finishing setup within the same minute must be able to both request a range and get adjacent, non-overlapping results with no coordination between them. That is the whole point of atomic reservation: correctness does not depend on the two operators talking to each other.

Audit history and traceability

Keep every reservation on record: which range, which portfolio, which site, when, current status. When a support case or a compliance question asks "was this identifier one of ours, and when did it ship", the answer is a lookup, not an archaeology project. The tool is append-only for this reason: nothing is deleted, so the trail is always complete.

Released vs permanently shipped ranges

A reservation ends in one of two terminal states:

• Shipped means the units went out. The range is now permanent and can never move back. This is what makes a later "did we ship this" answerable with certainty.
• Released means the range was reserved but not consumed, and is available again, but only as an explicit starting point that someone chooses. It is never auto-recycled.

Avoiding accidental range reuse

Accidental reuse is designed out by three rules: nothing is deleted, released ranges are opt-in only, and a released range that has since been drawn on cannot be reactivated. If you want the range back, you take a deliberate action and the system checks it is still safe.

Contract-manufacturer workflows

For the full handoff, see how to share MAC address ranges with a contract manufacturer. The short version: allocate them an isolated subrange, send a production-order export for each run, get back the list of identifiers actually programmed, and release whatever they did not use.

Reference: IEEE Registration Authority. To run central allocation for a block you hold, see MAC address allocation and plans.