What is DHCP Network Hint?

With the increase in popularity of laptops, it is very common for users to frequently reconnect to a previously visited network. In order to improve user experience in roaming scenarios, where the user connects back to a previously visited network where the user had a valid DHCP lease, DHCP network hint has been implemented in Windows 7 OS. DHCP network hint helps in identifying the correct DHCP configuration for a previously visited network and then using the configuration opportunistically. Network hint used in order to uniquely identify different network is SSID (Service Set Identifier) of a network


Scope of the feature is limited to all the networks that have associated SSID. So presently it is restricted to all Wireless (WLAN) networks.

Also, the feature is supported currently only for IPv4.



At present only Wireless (WLAN) networks are capable of providing the appropriate network hint. In lieu, the feature is applicable for Wireless (WLAN) networks only. The performance optimization will be seen only when a laptop machine revisits a network where he had a valid lease.


This feature enables improvement in laptop machine’s network connectivity experience in connecting to different Wireless (WLAN) networks in mobile/roaming scenarios by substantially reducing the time taken to acquire an IP address on revisit to a network.

Example Scenario

A user roaming with his laptop from office to home and back to office is a very common situation. This feature will be of good significance in such scenario.

1)      A user is in Wireless (WLAN) A network (office network).

2)      He moves to Wireless (WLAN) B network (home network).

3)      Now when he comes back to Wireless (WLAN) A network, he will see significant improvement in the time taken to get the connectivity as compared to time taken to get the network connectivity when moved in a network for the first time.

Comments (10)

  1. Anonymous says:

    Could this error be an indicator of a tapped network or listener of some kind?

  2. Anonymous says:

    This just struck me as geeky-cool (a term I use far too often, but that’s because I thrive on geeky-cool

  3. teamdhcp says:

    What error are you encountering and in which scenario.

  4. Anonymous says:

    Can you please elaborate more on the security functionality and share the write up you have.

    We appreciate your suggestion.



  5. Anonymous says:

    Nopes SSID broadcasting need not be on for all devices. For whatever devices it is on, performance improvement will be seen.

  6. someone says:

    Should the SSID broadcasting be on for all devices?

  7. Dave says:

    This has applications well beyond just being geeky-cool, since it provides a very useful piece of security functionality as well.  You can use location-awareness provided by this mechanism to reduce the amount of exposure in a mobile device by having it reduce its network footprint (trying to connect to servers, UPnP, printers, etc) if it detects that it’s in a foreign network.  At the moment stuff like this is being done in an ad-hoc manner using MAC-based mechanisms, but having it as out-of-the-box functionality would be a nice security feature.  I have a much longer writeup on this that I could post if it’s of interest…

  8. Dave says:

    Oh, and a followup question: Why is this keyed off the non-unique SSID rather than the guaranteed-unique MAC address?  What happens when you’re in an environment where every second SSID is "Linksys"?  Just curious about why the SSID was chosen over the MAC address.

  9. Dave says:

    Sure, I’ll send it via the email contact page since it’s kinda long. For the general readership, it’s a reverse of the standard concept of a location-limited channel/data tether (also known as geographic entitlement) where access control is handled via location.  So for example to perform secure setup on a wireless device you press a button on both devices within a few seconds of each other, because the one thing a remote network attacker can’t do is perform operations with the physical device.

    What this does is the inverse of that access model.  Normally location-based access says "Where am I, and how much stuff can I reach from here?".  So when you fire up a laptop running Windows it looks for a network and then sends out printer solicitations, UPnP stuff, NTP requests, tries to connect to network shares, basically it spreads a huge footprint (and therefore a huge attack surface) all over the local network (I was amazed when I ran a network sniffer just how much network exposure there is for a standard Windows box, there were messages bouncing around that really shouldn’t be sent automatically).

    Instead of doing this, the inverse location-based security mechanism says "Where am I, and do I really want to expose myself to anything on this network?".  So if you recognise the gateway MAC address as a known-good one you go ahead and expose yourself over the network.  If you don’t, you do a minimal DHCP with as many bells and whistles as possible turned off, and then check with the user to see whether they want to treat this as a trusted network.  At the moment the only way to achieve this is to manually turn off all the services that grope around on the network as soon as a connection is established, which is a suboptimal way to do it.