Microsoft's AutoNet Technology

Choosing IPv4 Addresses in the Absence of a DHCP Server

Background

AutoNet refers to the Windows 98 / NT5 functionality that lets a machine assign itself an IP address in a specific subnet in the absence of DHCP servers. This is functionally equivalent to the IPv6 Stateless Auto-configuration capability, which allows IPv6 machines to assign themselves valid IPv6 addresses.

The subnet in which AutoNet assigns addresses should not be routed, and all traffic will stay within the machine's physical subnet. (Just like a link-local address in IPv6.) Network traffic from this machine should not cause any problems with other machines on the subnet.

Why Did They Do It

Currently, Microsoft Operating Systems are undergoing a lot of changes. One of these changes is the migration of all network services to a TCP/IP based solution. Unfortunately, the differences between TCP/IP and IPX / NetBEUI (the currently used network protocols for many MS network-based services) are causing a few headaches. One of these differences is the assignment of addresses.

Under IPX, a machine's local address is based on the unique identifier supplied with it's Network Interface Card. (This identifier is in IPX what an IP address is in IP.) Because the address is based on unique identifiers on the local machine, users do not need to configure anything to get IPX services to work. IPX is a plug-and-play network mechanism.

IP, on the other hand, it not as simple to configure. Machines using IP based services have an IP address to uniquely identify them on the network. This address is not dynamic, and must be assigned by the administrator for the local network segment. Typically, this is done via protocols such as BOOTP and/or DHCP. When a machine with an IP stack boots, it sends out a DHCP request, and the DHCP server assigns it an IP address, based on the NIC's unique identifier, and the machine's location on the network.

Microsoft is targeting their Operating Systems as the solution for everything, from corporations to small businesses to homes. Not all of these locations have DHCP servers running, yet MS wants IP based solutions to work even on an ad-hoc network of just two machines. So, the machines must choose IP addresses for themselves.

How AutoNet Works

In Win98 (and the pending NT5), client machines send out a DHCP request, and wait for a response. If they do not receive a response from a DHCP server within a specific timeout period, they assume that the local network is a private network, and intelligently choose IP addresses in a specific range.

When the network consists of a bunch of machines that are using IP to communicate with each other without an IP infrastructure (DNS or DHCP), this solution works well. In large networks utilizing DHCP, the AutoNet functionality is not used, and thus does not cause any problems.

AutoNet addresses should not be routed off of the local subnet, so even in large networks, machines that have incorrectly assigned themselves addresses (due to the DHCP servers being down, etc) will not adversely affect others on the network. (However, we have noticed that, due to our router configuration, packets destined for AutoNet addresses actually make their way out of our network. The routers see these packets, and forward them upstream, as they know the packet is not destined for a subnet downstream. To avoid placing unnecessary traffic on our ISP and beyond, we will actively stop packets destined for AutoNet addresses from going offcampus.)

Finally, machines that have assigned themselves AutoNet addresses will check to see if a DHCP server has come up, by sending out DHCP requests every 5 minutes. If the machine receives a DHCP response, it changes it's IP address to the one assigned by the DHCP server, and restarts the IP stack. This may be a problem if a DHCP server is introduced into a planned ad-hoc network.

Why AutoNet Causes Us Problems

We assign IP addresses in a slightly different way. We require all users to register their machines with our central computing group. The DHCP servers only hand out IP addresses if the incoming DHCP request is for a registered machine. If the machine is not registered, no response goes out.

Previously, if a Win95 machine was unregistered, when it failed to get a DHCP response, a dialog box would appear that said:

Failed to obtain a lease from the DHCP server.

The user would call our help desk and ask what this error message meant, and it was very easy to see what was causing this problem.

Now, with AutoNet, the user does not see this message. Instead, the machine gets an IP address that does not work on the network. Users will see different problems based on what they are trying to do -- they will only be able to communicate via IP with other AutoNet addressed hosts on the local subnet. All other IP based services (DNS, Email, Web, etc) will not work.

What Can Be Done

At this time, there isn't much we can do to stop this. However, we have proposed a solution that would not interfere with the existing AutoNet functionality, but would help sites such as ours turn this functionality off. If Microsoft responds favorably to this request, we'll follow up on it with the IETF.

Our proposal is to add another DHCP tag that allows a host to ask whether or not it should AutoNet when it asks for an IP address.

When a DHCP server responds with a DHCPOFFER, this offer will contain the same tag, with the response set. If the IP address offered is 0.0.0.0, and this tag is set to "Do not AutoNet", then the host should not choose an AutoNet address.

If a client does not send this new tag in it's DHCPDISCOVER, servers respond or not as they did before.

If a client does set this new tag in it's DHCPDISCOVER, servers have a choice to make:

Servers that want to make a normal offer will send a DHCPOFFER.
Servers that do not know about this tag, and do not know about the client, will not send anything.
However, servers that DO know about the tag, and do NOT know about the client, will send a 'bogus' DHCPOFFER that says "Do not AutoNet".

Client functionality remains (almost) the same:

If a DHCPOFFER is received, and it contains a valid address, continue normally.
If a DHCPOFFER is received, and the IP address is 0.0.0.0, check the AutoNet Tag. If the tag says to AutoNet, and no other DHCPOFFER is received, use AutoNet.
If a DHCPOFFER is received, the IP address is 0.0.0.0, the AutoNet Tag says to NOT AutoNet, and no other DHCPOFFER is received, do not AutoNet.

If a client receives multiple DHCPOFFERs with the address 0.0.0.0 which have conflicting AutoNet Tags, do NOT AutoNet.

Into The Future: IPv6

AutoNet functionality will disappear with IPv6, as this functionality is built into IPv6. IPv6 has "Stateless Address Auto-configuration" functionality that will allow a machine to assign itself a unique link-local (non-routed) IP address good only on the local subnet. The same advantages and disadvantages that AutoNet has apply to this technology, with one big exception: it's possible for a site to disable this network-wide.

IPv6 defines both a stateful and stateless address auto-configuration mechanism. Stateless auto-configuration provides the same functionality of AutoNet: machines choose an address without any configuration; while stateful auto-configuration requires configuration information fetched via DHCP.

As with AutoNet, DHCP servers may choose not to respond to an IPv6 host's request, and that host may pick an address and use it instead. However IPv6 router advertisements contain a piece of information that says whether or not stateless auto-configuration should be used on the local wire. If the router advertisement says "Stateless Auto-configuration should NOT be used", IPv6 machines that do not receive DHCP responses will not have an address.

For more information on stateful and stateless auto-configuration, check out the following IETF documents:

S. Thompson, T. Narten, IPv6 Stateless Address Autoconfiguration , RFC1971 , August 1996.
S. Thompson, T. Narten, IPv6 Stateless Address Autoconfiguration , Internet Draft, draft-ietf-ipngwg-addrconf-v2-02.txt , February 1998.
J. Bound, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) , Internet Draft, draft-ietf-dhc-dhcpv6-12.txt , March 1998.
C. Perkins, Extensions for DHCPv6 , Internet Draft, draft-ietf-dhc-v6exts-09.txt , March 1998.

Ryan Troll ryan+@andrew.cmu.edu
June 1998