11

I have to connect to a router with a static IP and subnet (machine automation, not internet). In ipconfig, subnet mask shows the subnet address I inputed but the IP is assigned a different one from the address I inputted. The previous computer connects properly and the only difference I notice in ipconfig is the new computer has "Autoconfiguration IPv4".

What is IPv4 Autoconfiguration? IP should be assigned from the router's DHCP, and if there is a IP-MAC conflict I should receive an error message. Why is IPv4 Autoconfiguration appear in PC's command prompt instead of the usual IPv4 in this case?

Googling yield a solution but that require modification of the registry to disable Autoconfiguration. I had already had the latest driver update. I suspect there is an alternative solution.

enter image description here

6
  • Please provide a screenshot of the network connection’s IPv4 properties, where you entered your desired IP address etc.
    – Daniel B
    Aug 22, 2017 at 6:09
  • Picture uploaded. As you see I set IP to be 100.0.0.255/255.255.0.0 but ipconfig shows Autoconfiguration IPv4 169.254.196.218/255.255.0.0
    – KMC
    Aug 22, 2017 at 6:55
  • It might be that Windows incorrectly assumes that .255 is an incorrect IP, but it is valid with that subnet mask. Did you try any other IP addresses?
    – Paul
    Aug 22, 2017 at 6:59
  • Unfortunately I cannot since the device is fixed sending message only to 255. Why would OS autoconfiguration IPv4? Shouldn't that be the job of the router's DHCP?
    – KMC
    Aug 22, 2017 at 7:11
  • Just making sure: You’re positive you set up the correct network adapter?
    – Daniel B
    Aug 22, 2017 at 7:19

4 Answers 4

14

The screenshot shows an IPv4 address that start with 169.254.

This is from the "link local" range (e.g., RFC 3927 page 31 discusses what Windows XP using these addresses). Some people call these addresses "APIPA" addresses, named after Windows XP's process called Automatic Private IP Assignment (APIPA).

It seems that as technology has advanced, there are now two causes that commonly resulting in an address in this range.

  1. Windows will use this if it is set to use DHCP, and it tries to get an address from a DHCP server, and fails.
  2. "Duplicate Address Detection" ("DAD") has resulted in noticing an IP address conflict. From the comments that have been made, it seems that the feature of "Duplicate Address Detection" detection may also result in automatically assigning a different IP address, even if an IP address is statically configured.

The potential fixes to having such an address can be:

  1. check the logs to see if there is anything mentioned about a duplicate IP address. If so, try to determine what other device had that address, and why it did. If it got that address by DHCP, try to determine which DHCP server was used by each address that got that address, and troubleshoot the DHCP server(s). (Note that accidentally having an unknown extra DHCP server might be a common cause for this.)
  2. get DHCP communication functioning successfully,
  3. or to go to the NIC properties and specify an "Alternate Configuration" process that uses a specified "User configuration", or to use a static IP address.

Why DHCP isn't working is a separate question. This is the correct answer for specifically what you asked, which is: "What is IPv4 Autoconfiguration".

As for why DCHP overwrites static IP: DHCP usually doesn't. If you see an Autoconfiguration address in Microsoft Windows, then you're not using a "static IP" assignment. (Instead, you're configured to be trying to use DHCP, or DAD is taking effect.)

According to one comment (which was made via a proposed suggested edit), newer versions of Microsoft Windows may silently set an autoconfig IP (instead of showing a message on the screen). This is likely caused by DAD.

Trying to disable DAD might not be a great way to fix the problem, as that may cause the computer to start working on the desired IP address, but not address the issue that another device is trying to use the same IP address (which may cause problems immediately, or later when the other device starts being more active again).

3
  • It's worth noting that in the time since this answer was written, RFC 3927 has been rejected. Jun 6, 2022 at 14:11
  • 3
    @BrettHolman I don't see that being the case. Having reviewed this (because I understand an RFC may be deprecated/obsoleted, but never heard of an RFC being "rejected"), I've determined that Errata ID 6293 has been rejected. Errata ID 6293 seems to be a proposed complaint/correction/update about RFC 3927, and this Errata was probably rejected due to a procedural concern: the rejector seems to indicate that if that text is going to be properly updated than that should happen by drafting a new RFC, not making an Errata on the old RFC. (So the RFC itself was never "rejected" that I can see.)
    – TOOGAM
    Jun 15, 2022 at 18:43
  • Thank you for the clarification, I mistook the attached Errata rejection for rejection of the RFC. I really appreciate the response :) Jun 16, 2022 at 14:38
7

As the alternative to editing registry you can try this solution:

  1. open command line
  2. check id of network connection - it will be in the 1st column: netsh interface ipv4 show inter
  3. run this command replacing <id> with id of your network connection: netsh interface ipv4 set interface <id> dadtransmits=0 store=persistent
  4. open services.msc and disable dhcp client
  5. disconnect network cable, restart computer, start dhcp client service and plug in network cable

source: http://the-it-wonders.blogspot.com/2013/04/autoconfiguration-ipv4-address-196254xx.html

Since I can't add comment to TOOGAM's answer: autoconfiguration apparently can overwrite static ip configuration. Today I had a laptop (with Windows 10, version 1709) that couldn't access network and had both static ip and autoconfiguration ip visible in ipconfig output even though I put static ip in network card configuration.

3
  • Thanks jacob_w. This happened to us today too for no apparent reason, and your fix made it work. We've done many machines the same way and this is the first time we've seen this, so go figure. If anyone works out the actual reason this happens, please post.
    – radsdau
    Jun 12, 2018 at 6:11
  • I feel pretty certain that steps 4 and 5 could be replaced by this: run IPConfig /release and then run IPConfig /renew. That may take a while, but would be faster (and easier) than the steps 4 and 5 provided, and would fully accomplish the critical steps that would happen by performing the longer steps 4 and 5 listed here. The basic reason either approach (either version of steps 4 and 5) would work is simply re-attempting a DHCP Discover or DHCP Request communication.
    – TOOGAM
    Dec 15, 2019 at 14:24
  • If that works, the typical real problem is unreliability with the DHCP process. That could happen due to bad networking (bad center of cables, loose connection in the connectors of cables, wireless signal interference, filled DHCP scope which may randomly have an available address based on other devices)... maybe too many possible causes to list them all here, but not caused by a bad registry setting.
    – TOOGAM
    Dec 15, 2019 at 14:28
1

I had the same issue and in my case i had a static IP

So the Comment by another person "As for why it overwrites static IP: It doesn't. -- Is Incorrect

In my scenario it was one of the VMs and there was another VM with the same IP. Instead of throwing the error about duplicate IP in my case it performed Auto Configuration

4
  • 1
    this was my issue. i'm working with a printer that has a static ip of 192.168.123.100. I connected this printer to my laptop through ethernet, and also set the NIC ip to be 192.168.123.100, but because it conflicted with the printer's ip, the NIC defaulted back to 169.254.
    – Simon
    Sep 12, 2019 at 18:22
  • On professionally-run networks I've encountered, we didn't typically have encounter duplicate addresses, so "duplicate address detection" wasn't actively affecting things. The "Obtain an IP address automatically" option basically boiled down to attempting DHCP, and if that failed, using the Alternate Configuration tab (which was usually unconfigured, resulting in APIPA assigning an IPv4 (169.254.*) link-local address. The "Use the following address" option resulted in a static IP, not causing DHCP or Link-Local to work.
    – TOOGAM
    Dec 15, 2019 at 14:41
  • I suspect that if Duplicate Address Detection (DAD) is being particularly useful, that may be because of some sort of issue with DHCP (e.g., server doesn't exist on the LAN being used, which may be quite likely with some "virtual machine" setups... or a filled DHCP scope, which may be remedied with an increased scope size or figuring out what is using up the addresses in an existing scope). My inclination would be to figure out why DHCP is not being a working, reliable solution, and trying to address that as a problem. (Of course, that works for me, who knows how to set up/troubleshoot DHCP)
    – TOOGAM
    Dec 15, 2019 at 14:44
  • 1
    Question is about static IP
    – SeanClt
    Dec 15, 2019 at 15:21
0

I had the same issue. I read that this is because the NIC card is not working properly, even though the Ethernet card said it was working properly. I have an HP desktop computer. I went to HP support, downloaded and reinstalled the Realtek Ethernet Controller Drivers for it and it fixed the card problem. No more autoconfiguration ipv4 address. Hope this help others.

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : 00-25-AB-5F-19-D9
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::a5e1:5447:5977:52d1%6(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.16.0.2(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, June 24, 2019 12:13:23 PM
   Lease Expires . . . . . . . . . . : Tuesday, June 25, 2019 12:13:22 PM
   Default Gateway . . . . . . . . . : 172.16.0.1
   DHCP Server . . . . . . . . . . . : 172.16.0.1
   DHCPv6 IAID . . . . . . . . . . . : 100672939
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-23-E0-22-28-00-25-AB-5F-19-D9
   DNS Servers . . . . . . . . . . . : 172.16.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Wireless LAN adapter Wi-Fi:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek RTL8188EE 802.11 bgn Wi-Fi Adapter
   Physical Address. . . . . . . . . : 38-B1-DB-6D-40-14
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

C:\Users\
1
  • 2
    You say "No more autoconfiguration ipv4 address." But that's wrong, based on the output you quote, as the output says "Autoconfiguration Enabled . . . . : Yes". What is true is that you didn't get an Autoconfiguration address from the "Link-local" (IPv4 169.254.*) range. Instead, your Autoconfiguration successfully got an address from the DHCP server, which is identified in your output on the line that says "DHCP Server . . . . . . . . . . . : 172.16.0.1". So whatever device is at 172.16.0.1 (which is also your Default Gateway, so is some type of router) served you well, with DHCP.
    – TOOGAM
    Dec 15, 2019 at 14:32

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.