My company makes Ethernet devices. These devices have very little I/O. No keyboard, no video output. When the customer gets the device he must configure it for his network. I'd like to choose an IP address that won't conflict with an existing device on his network, but his network could be anything.

Some customers has 192.168.x.x networks. Others have 10.x.x.x networks.

Most network equipment (routers in particular) ship with 192.168.x.1. But this is not a router, so I don't want to default to a low IP address as this will have a higher probability of conflicting.

What is a good IP address to ship with a product? Are there semi-private/unused Class C networks?

migrated from stackoverflow.com Aug 4 '10 at 13:47

This question came from our site for professional and enthusiast programmers.

  • 10
    The term "Class C" is dated and no longer relevant. I would recommend forgetting anything you know about "classful" routing and subnetting. Now. – Evan Anderson Aug 4 '10 at 13:53
  • What devices? Makes a difference, factually. Do they have a local chardware that can be used to configure them (LCD display, some buttons)? – TomTom Aug 4 '10 at 13:55

11 Answers 11


Let it be assigned by a DHCP server? if not I would suggest using But DHCP is definitely preferred

  • 3
    To configure the device the customer has to get to the built-in web server. How do you find the device if it is dynamically assigned? – Robert Aug 4 '10 at 13:29
  • You can add DNS as well :) – codymanix Aug 4 '10 at 13:30
  • 1
    +1 for DHCP. not sure about the static ip address suggestion – Nick Kavadias Aug 4 '10 at 14:04
  • 3
    You're asking your customer to add a device to a network they don't control. IT Admins WILL get involved, once they find out that an unauthorized device is on their network. At least any IT Admin worth his salt. By saying you're going to default to a 192.168.0.X address, you're binding yourself to host networks that use the 192.168.x.x private address space. What if your customer connects to a network using 172.16-172.31 addresses? OR 10.x.x.x addresses? – peelman Aug 4 '10 at 15:45
  • 1
    Another vote for DHCP by default. If on a larger network or remote location, the person/network admin can set up fixed-address DHCP allocations based on the device MAC. If on a local subnet, the user can just ping the local broadcast address then look at/grep the arp table for the MAC. – Jeremy M Aug 5 '10 at 4:28

Avoid any fixed address. Even if you try to avoid addresses commonly found for other kinds of devices (like routers), you still should ask yourself: what if the user has two or more of this device?

As many people stated, you should try to automatically configure the device using DHCP. In this way, the network administrator can easily control the address of your device in a centered manner from the DHCP server.

Failing to configure from DHCP, your device should configure a link-local address in the 169.254/16 range. Any host connected in the same link with a compliant stack and non-broken configuration should be able to connect to your device using the default link-local address, and then configure it to the desired address.

RFC 3927 describes in detail how a device configures its link-local address. The abstract of this RFC reads:

To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.

The solution seems to be a perfect fit for your problem.

In short, the actual implementation described in the RFC consists in choosing a PRN using the device's MAC address as a seed. In practice, many devices that I saw use the last two octets of the MAC address as the last two octets for 169.254.x.y, and in case of collision, get a next number from the PRNG.

PS: I'm actually surprised that in 10 hours and with 8 previous answers, nobody mentioned link-local addresses. Unfortunately, now that this question is old and has an accepted answer, it is likely that this answer will be missed by most people.

  • 1
    DHCP is the sensible way to go but you get a +1 for mentioning the link-local address for those networks which don't run DHCP. – John Gardeniers Aug 5 '10 at 1:07
  • Link-local addresses are also known as Auto-IP or AutoIP addresses. – Mark Lakata Apr 23 '13 at 6:02

There are actually protocols designed specifically for the puroses of discovery. One example is the Link Layer Discovery Protocol (LLDP). If you really want a reliable solution you should probably consider something like this.

One problem with just picking a static IP is that whatever IP you pick it is unlikely that routing configuration for the computer attempting to connect to it will be set up correctly on all computers.

  • I don't think LLDP actually deals with assigning IP numbers. – Mark Lakata Apr 23 '13 at 6:06

DHCP and DNS might be a good solution if it wasn't for the fact that plenty of networks out there still have no server present and use fixed IP addresses. If you don't want to lock those people out from using your device then you at least need to fall back to some other system.

ZeroConf was invented to deal with just this situation: no DHCP or DNS server. Indeed it would solve this problem very well - the device assigns itself an AutoIP address, and then advertises its services so you can find it regardless of its IP address. The trouble with ZeroConf is that users need to install software on some operating systems in order to support it (e.g. Windows), and some client operating systems might not have a ZeroConf library available at all. The same goes for other proprietary discovery mechanisms that use a bit of proprietary software to configure devices' IP addresses.

My preference would be to default to DHCP with a known DNS name (as long as only one device will come up on the same network at the same time), but fall back to one of the following if no server is available:

  • ZeroConf: AutoIP for address allocation with DNS-SD for discovering the device. This works well when you have multiple devices that might be connected on the same network so you don't need a unique DNS name as well. The user doesn't need to know an IP address or a DNS name, and can find it in a list (which is a benefit over using DHCP and DNS if you need to support multiple devices on the same network at the same time). The downside: needs client software and might not be supported on some operating systems. Incidentally I include other similar service discovery protocols in this bracket.
  • Proprietary protocol: Reinvent the ZeroConf wheel. Advantages are that this is simple to implement, but it does mean that you limit the number of client operating systems that can set your device up (depending on how many OSes you write an app for (e.g. do you need iPad support?)).
  • Fixed IP address: This is the system which most routers etc. use so is fairly tried and tested, and can be made to work on pretty much any client operating system. The trouble is that your IP address may clash, which of course is the point of your question. In this case I would suggest you choose any in the range but make the documentation strongly suggest connecting directly to the device rather than via a wider network.

I realise you're probably just looking for a good relatively unused IP address, but these are alternatives worth considering if you can spare the man hours to implement them.


I've always prefered to set IP configuration directly on a device before connecting it, either via an panel or serial port. But the trend these days seems to be to only have a network port, so the best approach would be to default to DHCP, then fall back to 169.254.x.x link-local addressing, and perhaps use multicast service discovery (ZeroConf/Bonjour) so you can find the new widget's current address in order to give it a new one. Also, make sure the MAC address is on a readable label on the outside of the device.


Another Private Range is mask

This range would consist of all IPs from 172.16.x.x to 172.31.x.x esentially 16 Class B Subnets.


Several years ago I came across a device which came without any default ip address or dhcp client. Instead you set the ip address using arp and ping. There's online documentation for an Epson printer with a similar option. This particular device also came with Windows software which would send the arp and ping commands for you.

  • HP and other printer servers used to do something similar. But as Evan said 'RARP... in 2010 can you believe it???' – BillN Aug 4 '10 at 22:53

1st I would set it to get some variation of 192.168.x.x/24. say

then I would provide very clear and detailed documentation to enable user to:

if the person has a different network address they can temporarily change the ip on their PC to to an address on that network such as

then they should be able to get into a web interface that asks them to manually set an address or use DHCP. if needed a user could directly plug network cable from PC to device.

this is one cheap way to do it. most routers do it this way -but use or 1.1. A more expensive way is to use DHCP at 1st and write or buy a discovery utility.


I would use 192.168.x.y where x and y are random numbers excluding 0, 255 and 1 for y. Since you want to avoid conflict, it doesn't make sense to pick some 'good' default address, because others would then pick the same address.

They might even get it from this question.


As long as the user can change the default address, it does not really matter.

If it is a consumer product, I would definitely put it into the 192.168.x.x range.

  • was the default ip on a device for the home market I was configuring today and that worked beautifuly for us because the router as shipped gives out ips in the range – kaerast Aug 4 '10 at 21:59
  • @zwip, how will the customer readily access the device if the default IP address is in a different subnet (non-admins rarely understand routing). What if that address clashes with existing devices? Yes, it DOES matter. – John Gardeniers Aug 5 '10 at 1:05
  • You should really be testing new devices on a non-live network first to make sure it doesn't take down the entire network by doing something bad. So no, it doesn't really matter because you can configure it 'offline' first. – kaerast Aug 5 '10 at 9:53

Could the device send a broadcase first and then after receiving answer from multiple IP-addresses you chose one from which you got no answer. Maybe you can use the address which is one higher than the highest address which answered.

Maybe in some cases a default value is not good at all, so you may ask the use for one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.