I am working at one new device with network connectivity, I would like to ask what behaviour is expected by network experts when device is not able get IP address from DHCP server (IPv4). I have some ideas, but I am sure which way is best and most straight forward for end users:
Use AutoIP (RFC3927). That means automatically assign address at range 169.254.1.0 - 169.254.254.255.
Assign static IP address. This IP address will be configurable via web GUI.
Assign static IP address from range 192.168.1.x which will be hardcoded inside FW.
Do not use fallback options and keep waiting for DHCP server. Maybe this can work as well, because I plan to have IPv6 too.
Let’s say I assign fallback static IP, should stop waiting for DHCP server response or not? That means when DHCP server assign IP address I will change address from fallback to address from DHCP server. Personally such behaviour does not sounds me straight forward, but I can be wrong.
Feel free to comment and I will be glad for any input or idea.
The easy way is to configure your new device as DHCP. When the device boots up, it will ask the DHCP server for an ip. The 169.254.x.x is called a link-local address indicating the device could NOT get an ip (DHCP server is not reachable). If you want to set that device with a static ip, pfsense allows you to change the mapping (Status > DHCP leases > Add static Mapping).
It seems that I did not described my question clearly. I am developer of Ethernet devices and I am developing new device. At current generation of devices I use AutoIP feature. With new generation I move device to different IP stack and I am wondering if this can be done by better way. Theoretically I can implement into my firmware almost anything. I would like to know what behaviour of DHCP fallback option other users expecting.
Of 20+ years of IT (some spent developing products) I would say products fall in two categories.
Preconfigured for DHCP, and fall back to Automatic Private IP Addressing (APIPA, 169.254.#.#). That behaviour may even be part of the DHCP specification.
Preconfigured with a known IP address, such as 192.168.0.250
Personally I prefer the DHCP method as almost all networks run DHCP. However, if the device is for home use that may or may not be convenient. For example, if the end user has to know the IP address to configure the device, as most home users wouldn’t have a clue how to find out that information. In that scenario there is usually an app (computer or phone based) that will allow you to ‘search’ the network for the device using a broadcast. Or better still, implement mDNS on the device to find it via a .local name.
Thank you for a comment. I am developing wired and wireless devices for 12 year, but always is good to ask someone with more experiences.
I use both approaches which you described:
Our (my) Ethernet devices (older design) are shipped with static IP. End user can enable DHCP at devices setup. When device is enabled, AutoIP (APIPA) is used if DHCP server is not reachable. For discovery is used our proprietary protocol via UDP broadcast.
Our (my) WiFi devices are shipped with enabled AP mode. At first step customer need to provision device into WLAN, set network parameters, etc. By default is used DHCP with AutoIP fallback. For discovering is supported our proprietary protocol and mDNS as well. IP address can be shown at LCD display too.
AutoIP is not a mandatory part of DHCP according RFC. But is commonly used, because it make sense. I also saw some device with DHCP fallback to static IP at 192.168.1.x subnet. That is reason why I opened this thread.
mDNS is nice but natively works at Apple devices only. mDNS is not supported by Android devices. Windows uses for resolving .local LLMNR protocol instead mDNS.
It sounds like you already have a good setup that works well. As I said, my preference is for DHCP rather than static out of the box. One reason being, I can plug it straight in the network. With devices that are shipped with a preset static IP, you always run the risk of introducing an IP conflict on the connected network, if that network happens to use the same address space. I’ve seen both methods though used by the big manufacturers, and even the same manufacturer use different methods for different products.
I would certainly avoid falling back to a static 192.168.#.# type of address if it ships with DHCP. That just seems like an unexpected thing to happen, and has the potential conflict reason mentioned above.
I agree mDNS isn’t the perfect solution, especially with Android lacking support and it often being disabled in Linux by default (if it even is supported out of the box). However, it has been in Windows 10 since the 1703 update, so has been around for a while. Personally I’ve never used it as it wasn’t really a thing when I was last working with product development, we just did the same a you and used a proprietary UDP broadcast.
My preference for new devices is to come pre-configured with an IP address. For me, this is the fastest way to connect to it to make the required site-specific configuration. If the new device is set up for DHCP out of the box, after I connect it, I have to figure out what address it has, either by it looking up in the DHCP server, setting up a static reservation, or using some tool to scan the network.
If the device configuration is then set up for DHCP I think it should fall back to a self-assigned address rather than some pre-set address if DHCP fails. This would avoid any possible IP address conflicts if the pre-set address happens to be in the same subnet as the LAN it is placed on.
I’m completely opposite. If I get three or more POE powered cameras (for example), there are a couple of things I’d really like:
#1 make absolutely certain that the MAC address is on the box or outside of the device. This way I can set a DHCP reservation before connecting it. I can remove the sticker if I feel it is a security risk, but having this information for initial work is important to me and many other network admins for a lot of reasons.
#2 I would like DHCP with fallback IP. I’d also like to set this fallback IP myself during initial configuration. That way if my DHCP fails, the device will fall back to a known state ,whatever I programmed or link local if nothing is programmed.
Thanks for your valuable feedback. Obviously everyone have own preferences.
It is likely that I will use DHCPv4 as default with AutoIP. I will use IPv6 with SLAAC as default as well (end user will have option to st static IPv6 or use DHCPv6). At device factory label at current devices we have serial number and MAC address. Same approach I will use with new devices.
The only thing I still have to figure out is to “recovery” from Auto IP when DHCPv4 server is online again. My ideas was check DHCP server every 20 minutes when IP is assigned by Auto IP and there is no socket communication via IP 169.254.x.x. Implementation of such thing will be slightly harder, but I think manageable. Main reason why I need to implement recovery from Auto IP is that my device online at 2-4sec, that means much quicker that DHCP server. And recovery from local power failure need to work.
