Best choice of private addresses for a "device area network"
@yoonix has sent a link that might have a solution.
Link-local, also known as APIPA.
169.254.0.0/16 - This is the "link local" block. As described in RFC3927, it is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server cannot be found.
If I were your customer, I'd sure as hell want to have the option to configure this myself and/or use DHCP (which is, I don't know, maybe a long-established standard?), but in the absence of those, this is exactly what APIPA is supposed to be used for.
Edit - Given that you now state that the IP addresses must be static for individual hosts in your solution because those will correspond to firewall rules in your gateway device, I suppose that would take a bit of effort on your part to make that work with link local IPv4 addressing; effort you say you won't expend. So, you essentially have to make this configurable. You could ship it with a default, one that is less likely to be used by a client, but you must have a mechanism by which it can be changed in case of a conflict. Either by the client, or by you as part of implementation/UAT.
Make it configurable.
Should I buy IPv4 addresses?
Yeah. TRY THAT. First, you do not buy them, you "lease" them by membership. Second this requires an AS and 2 uplinks. Third, this requires a reason and "we do not want to suppose a proper network infrasctructure" is a reason resulting in laughter (and a rejection), not you getting IP addresses allocated.
Or maybe I can get away with using TEST-NET-3 (203.0.113.0/24)
Possibly. Until the day someone asks oyu for the cost of fixing things because of gross neglect.
What is the best practice?
Make it configurable. Or use IPV6 - there you can get away with some reservations.
From Wikipedia:
Assigned as "TEST-NET-3" in RFC 5737 for use solely in documentation and example source code and should not be used publicly.- This tells me that you should not use TEST-NET-3.One thing you appear to be overlooking: How do you suppose that you'll be able to communicate with the device or that the device will be able to communicate with other devices and vice versa if you don't configure the ip address of the device FOR the client network? If you assign an ip address in a network that isn't in use in the client network (You: 192.168.1.0/24 - Them: 10.0.0.0/8) then how do you suppose that network communication is going to work? This is why you should configure the device to use DHCP out of the box and allow for the client to statically configure it afterward.
If you can't use DHCP then use APIPA.
In theory, any private IP range could be in use by any private network, so I doubt you'll find a best practice, or anything that's going to be universally applicable if you're hard-coding the address. The best practice would be to make it configurable and allow the client network to assign the device a private address (via DHCP, for example).
If that's not an option, I find that hardly anyone uses the upper half of the 172.16.0.0/12, so that's what I use. (I think I'm running on 172.25.0.0/16, to be precise.) I've yet to have an address collision on it, and I VPN into a lot of private networks.
If you have to use an IPv4 private address, I think that's the best you'll be able to do, with the 10.0.0.0/8 block being widely used and the 192.168.0.0/16 block being the default for almost everything, the only one left would be 172.16.0.0/12. Of course, this block is often used for VPNs, to avoid address collisions, because of the widespread use of the other private network blocks, so use the upper addresses, since (in my experience) they're the least utilized subnets in that block.
We're designing the exact same thing and have decided to go with IPv6 site local addresses with a random fc00:nnnn prefix.