What is a good default IP address?

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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 192.168.0.0/24 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.

Answer 5

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.

Answer 6

Another Private Range is 172.16.0.0 mask 255.240.0.0

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

Answer 7

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.

Answer 8

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

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 192.168.100.101.

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 192.168.0.1 or 1.1. A more expensive way is to use DHCP at 1st and write or buy a discovery utility.

Answer 9

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.

Answer 10

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.

Answer 11

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.