Wouldn't it be nice if Rockwell would fix this properly?
I am not sure it is Rockwell's problem to fix.
If port 67 is already allocated to a process on OP's fairly new Windows 10 Pro laptop, it is likely that process is a Bootp server.
So one solution would be to tell that server, if that is possible, what IP address to give to the PLC when the PLC makes a Bootp client request.
TL;DR
IP ports are per-host resources in TCP/IP; there are 65536 of them.
If another server process on OP's laptop has already bound (allocated), and is listening to, port 67, that is OP's problem, not Rockwell's.
Background
Bootp is a client-server protocol using UDP: the PLC in this case is the client, which requests an IP address by broadcasting to UDP port 67 with its MAC address; the OP's fairly new Windows 10 Pro laptop runs a Bootp server process, which binds, and listens, to UDP port 67, maintains a list of which IP address goes with which MAC address, receives the broadcast from which extracts the PLC MAC address, matches (hopefully) the MAC address to its corresponding IP address in the list, and finally sends that IP address to the PLC via its MAC address.
If a server process on the laptop has already bound, and is listening to, port 67 on the laptop, then the resource "port 67" is allocated to that process, and any other process that is started will not be able to allocate that resource when it tries to bind to port 67 on the laptop.
Because if two server processes could be bound to the same port, and a Bootp client request came in, then how could the operating system know to which of the server processes the request should be sent?
Here are the steps a UDP server process, such as a Bootp server, performs:
- Create a UDP socket.
- Bind the socket to the server address.
- Wait until the datagram packet arrives from the client.
- Process the datagram packet and send a reply to the client.
- Go back to Step 3.
Cf.
https://www.geeksforgeeks.org/udp-server-client-implementation-c/