This document provides details of a DHCP issue present on the following platforms:
- • iOS 3.2.1 and 3.2.2 on the Apple iPad® (first generation)
- We have verified on the iPad (first generation), and assume it is also present on the iPad+3G (first generation).
- • iOS 4.0 on the Apple iPhone® and the Apple iPod Touch®.
- We have verified with iOS 4.0 on the iPhone 4, and assume it is also present on the iPhone 3G and iPhone 3GS.
We have verified with iOS 4.0 on the iPod Touch (third generation), and assume it is also present on the iPod Touch (second generation).
- • iOS 4.0.1 on the Apple iPhone®
- As the 4.0.1 update reportedly includes a single change (unrelated to this issue), we also assume that the issue is present in iOS 4.0.1 on the iPhone 3G, iPhone 3GS, and iPhone 4.
- • iOS 4.0.2 on the Apple iPhone® and the Apple iPod Touch®
- The 4.0.2 update reportedly includes a few changes unrelated to this issue. We have verified with iOS 4.0.2 on the iPod Touch (third generation), and assume it is also present on the iPod Touch (second generation), iPhone 3G, iPhone 3GS, and iPhone 4.
This document provides information for individuals who would like detailed technical information about the issue.
Although the issue is not one the owner of the device would notice, it can degrade service on a large network with many such devices.
Princeton University reported the issue to Apple, and worked with Apple to resolve the issue. Apple addressed this issue in iOS 4.1. (Note that Apple's fix introduced a new bug, described in iOS 4.1 - 6.1 Allows DHCP Lease to Expire, Keeps Using IP Address.)
DHCPv4, the Dynamic Host Configuration Protocol for IPv4, allows a device attached to the network to automatically learn some or all of its network configuration, including its IPv4 (Internet) address. Most operating systems include DHCP client software.
A device that uses DHCPv4 runs DHCP client software on a network (e.g., Ethernet or Wireless) interface. The DHCP client software contacts DHCP servers to obtain network configuration; in particular, it usually obtains a lease (a loan) of an IP address.
For example, the DHCP client broadcasts the request: "I am network interface 0:1:2:3:4:5; please lease an IP address to me." A DHCP server might respond: "You may use IP address 192.168.1.2 for the next six hours; if you would like to continue using that address, please renew it when three hours have elapsed." When three hours have elapsed, the DHCP client contacts the DHCP server which granted the lease; the client asks that server to renew the lease. Typically the DHCP server respond to the client: "You may use IP address 192.168.1.2 for the next six hours; if you would like to continue using that address, please renew it again when three hours have elapsed." (If the DHCP client is unable to contact the DHCP server to the renew its unexpired lease, it will retry from time to time, and is permitted to continue using the IP address until the lease is due to expire.)
Assuming the DHCP client successfully renews the lease before it expires, this repeats periodically until the device goes offline. Once the device is offline, it no longer contacts the DHCP server to renew the lease, so eventually the last lease renewal expires. Once the last lease renewal has expired, the DHCP server is free to lease the IP address to another client.
If the device goes offline, when it later comes back online it broadcasts a DHCP request for a new lease. It may choose to request a brand-new lease, or (if it believes the old lease has not yet expired) may request a new lease on the old IP address.
Under certain circumstances, iOS 3.2.1 - 4.0.2 requests a DHCP lease too often. Although the owner of the device will not notice any problem, this can degrade network service on a network containing many devices behaving in this way.
The device exhibits this issue when the following requirements are met simultaneously:
The requirements above raise the question: "In what situations does the device choose to remain attached to a Wi-Fi network while the device is asleep and it is not attached to a power source?" Such situations include (but may not be limited to) each of the following:
When the device chooses not to remain attached to Wi-Fi when the device is asleep and it is not attached to a power source, our experience is that the device disconnects from the Wi-Fi network not long (sometimes 10-15 seconds, sometimes as much as 90 seconds) after the device is put to sleep. (It may reconnect to Wi-Fi periodically if configured to fetch mail, contacts, and calendars via a periodic schedule, but it will disconnect once done fetching, rather than remain connected.)
While the device meets the requirements above, it requests a DHCP lease too often:
A device that remains online with a DHCP lease that has not yet reached renewal time should not need to request a DHCP lease in either situation above.
The device's DHCP behavior can easily result in an excessive rate of DHCP requests, as it is perfectly normal for the device to send IPv4 traffic or receive IPv4 unicast traffic quite often.
While these excessive DHCP requests should not be an issue in small or moderate size networks, they can degrade service in a large network where many devices exhibiting this behavior are attached. On such a large network, these excessive DHCP requests can degrade service for several reasons:
High levels of broadcast traffic degrade network service for all devices on that subnet. This is especially true on networks with limited capacity, such as wireless.
Often many IP subnets share a set of common DHCP servers; it is impractical to operate DHCP servers on each of many subnets. A BootP Relay Agent on each subnet is responsible for relaying the client's broadcast DHCP and BootP requests to the server(s), and conveying response(s) from the server(s) back to the client. The BootP Relay Agent functionality is usually provided as part of the subnet's IP router.
Excessive DHCP broadcast requests place unecessary load on the BootP Relay Agent.
Typically, adding additional DHCP servers will not add capacity if the requests are broadcast (as these are) and many of these clients are on the same IP subnet. Each of the DHCP servers for a given subnet processes all the DHCP requests that were sent as broadcast (as these are) by clients on that subnet.
For example, say the typical DHCP lease expiration time is three hours with a renewal time of 90 minutes. A properly-functioning DHCP client which remains online will renew its lease once every 90 minutes using a unicast packet. But a DHCP client that asks for a new lease as often as 10 seconds will send up to 540 DHCP requests during the same 90 minutes, and these requests will be broadcast rather than unicast.
While a small or moderate size network will not experience degradation from this traffic, a large network with many devices sending excessive DHCP traffic can experience degraded service.
This issue is related to the earlier iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address issue we observed. Both issues appear to be triggered by similar circumstances. Perhaps this new issue that debuted in iOS 3.2.1 was caused by the changes made in iOS to fix the bug that was in iOS 3.2. Take note that the issues are not identical. In iPhone OS 3.2, the device stopped performing DHCP yet continues using the DHCP-assigned IP address after the DHCP lease expired. In iOS 3.2.1 - 4.0.2, the device performs DHCP unecessarily often. The effect on network service is quite different.
When this "iOS 3.2.1 - 4.0.2 Requests a DHCP Lease Too Often" issue was in turn fixed in iOS 4.1, at the same time a new bug was introduced: iOS 4.1 - 6.1 Allows DHCP Lease to Expire, Keeps Using IP Address. That issue too appears triggered by similar circumstances. Probably the issue that debuted in iOS 4.1 was caused by the changes made in iOS to address the issue that was present in iOS 3.2.1 - 4.0.2. Again, the issues are not identical, and the effect on network service is quite different.
We reported this issue to Apple, and have worked with Apple to resolve the issue.
On June 30 2010, we published the first version of this document, covering iOS 4.0.
On June 30 2010, we published a Workaround for "iOS 4.0 on iPhone and iPod Touch Requests a DHCP Lease Too Often" Issue.. We viewed it as a temporary workaround, until a fix was available from Apple. Our testing also showed that sometimes that version of the workaround was ineffective; we referred to it as a "partial" workaround at that time.
On July 9 2010, we updated that workaround to add additional steps that we felt might improve its effectiveness.
On July 15 2010, we updated this document and the workaround to reflect that we expect iOS 4.0.1 for iPhone would exhibit the same issue as 4.0. This is because the 4.0.1 update reportedly includes a single unrelated change.
On July 16 2010, we update our published workaround to reflect that the July 9 revisions appear to have made the temporary workaround "fully effective."
On July 16 2010, we updated this document to reflect that the issue also affects iOS 3.2.1 on iPad. We also updated our published temporary workaround to reflect that it is also effective for iOS 3.2.1 on iPad.
On August 11 2010, we updated this document to reflect that the issue affects iOS 4.0.2 on the iPod Touch and iPhone. On August 12 2010, we updated this document to reflect that the issue affects iOS 3.2.2 on the iPad. We also updated our published temporary workaround to reflect that it is also effective for those platforms.
On September 8 2010, we updated this document to reflect that Apple addressed this issue in iOS 4.1 on the iPod Touch and iPhone. We also noted that the issue remained present for the iPad because iOS 4.1 was not released for that platform. We stated that we assumed the fix would reach iPad in iOS 4.2, expected in November 2010.
On November 23 2010, we updated this document to reflect that Apple's release of iOS 4.2 for the iPod Touch, iPhone, and iPad means that a fix is now available for all platforms.
Changes were made to Princeton's wireless network architecture beginning in September 2012 to accomodate the growing demand for wireless service. These changes included migrating from using globally-routable IPv4 addresses behind normal IPv4 routers to using private IPv4 addresses behind NAT routers, to accomodate a demand for more IPv4 addresses. And these changes included migrating from DHCP servers instrumented to detect malfunctioning clients to commodity DHCP servers, to accomodate growth in DHCP transacation rates from wireless clients. Side effects of those changes prevent us from detecting wireless clients exhibiting this issue. As we can no longer detect those malfunctioning clients, we no longer block these clients and contact the owner. As a result, malfunctioning clients still affected by this bug will degrade overall wireless network service on an ongoing basis.
We did not ban devices running iOS 3.2.1 - 4.0.2 from Princeton University's network.
When an individual device exibits this issue, we contacted the customer to advise him or her of the problem and refered the customer to the iOS upgrade. (Before an iOS upgrade was available to address the issue, we referred customers to our temporary workaround.) If the same device continued to exibit the issue (the customer did not upgrade the firmware nor adopt the temporary workaround until upgrading the firmware), we blocked that device from our network and contact the customer again. We removed the block once the customer addressed the issue.
If it was not practical to contact the customer (for example, because the device was using our visitor wireless service and the owner was anonymous), we blocked that individual device from our network. If at a later time it became practical to contact the customer (for example, because the customer registered the device in the University's Host Database), we contacted the customer to advise him or her of the problem and refered the customer to the iOS upgrade (Before an iOS upgrade was available to address the issue, we referred customers to our temporary workaround.) We removed the block once the customer addressed the issue.
This is similar to how we handle other malfunctioning devices which disrupt or degrade service. We typically do not ban entire classes of devices. We block individual devices after they actually disrupt or degrade service. In most cases, we unblock such devices when the owner takes acceptable action to address the issue. Device Blocking Policies describes these policies in greater detail.
As described above, architectural changes made to our wireless networks beginning in September 2012 to accomodate growth now prevent us from detecting clients exhibiting this malfunction. As a result, we no longer contact the owner of these devices or block them. Instead, these malfunctioning devices continue to disrupt and degade network service for others.
We can reliably reproduce this issue by following the procedure below. (We do not know if there are other circumstances that can produce the same issue.)
You may view the device's firmware version at: Settings -> General -> About -> Version.
The device will not indicate whether an email account supports Microsoft Exchange ActiveSync. If you are not sure, check with your email provider.
This availability of this setting does not mean that your device is in fact configured with an email account that actually supports Microsoft Exchange ActiveSync. The setting is always available. When set to On, the device tries to use Push to retrieve mail, contacts, and calendar, but for accounts that do not support Push, the device will instead use the periodic polling schedule (or "manual") specified on the same screen.
Use the Settings -> Mail, Contacts, Calenders -> Fetch New Data -> Advanced button on this screen to also view the per-email-account settings. Verify that the setting for your specific email account is also set to Push; that is, that the setting for this specific account has not overridden the system-wide setting.
You may look for running apps by opening the app drawer (double tap the Home button), and swiping through the drawer.
We suspect that applications which make use of the operating system's multitasking API to perform certain other network-related operations in the background (for example, to listen for incoming VoIP calls) might also prevent the problem from appearing. We are unable test until such applications become more widely available. If your device has any such applications installed, ensure they are not running.
You can do this my pressing the Sleep/Wake button, or by allowing the device to use its auto-lock feature.
In iOS 3.2.1 and 3.2.2, the "short time" varies from 30-45 seconds. In iOS 4.0 and 4.0.2, the "short time" is 10 seconds. We expect that iOS 4.0.1 behaves similarly to iOS 4.0 and 4.0.2.
You can easily induce this by pinging the device, or using a tool to send TCP or UDP unicast IPv4 traffic to the device.
If will also enter the DHCP INIT-REBOOT state when it wishes to send IPv4 traffic, if more than 10 seconds have elapsed since the device last obtained a DHCP lease; it performs the DHCP transaction immediately before sending the IPv4 traffic.
If you have access to your DHCP server's logs, you should be able to see the DHCP transactions.
A good way to observe the issue is with a wireless packet capture.
Instead of configuring the device to use email Push, we can also reliably reproduce this issue by configuring the device to enable Notifications (Apple Push Notification Service). That's done via Settings -> Notifications; that setting only appears if an application is installed which supports Notifications. If the device has a cellular interface, you may also need to disable Settings -> General -> Networks -> Cellular Data to reliably reproduce the issue using Notifications. That's because if the device has a cellular interface which has signal and is configured with Cellular Data enabled, Notifications (alone) don't appear to cause the device to remain associated to Wi-Fi when the device is asleep and there is no power source.
If you are attempting to reproduce the problem using email Push (as opposed to Apple Push Notification Service), take note: simply configuring the device with any email account and configuring the device to fetch mail via Push will not reliably reproduce the problem. If the email account provider doesn't support Push (for example, Microsoft Exchange ActiveSync®), the device will instead fetch mail using the perodic schedule (or manual retrieval) you have set. The user interface provides no indication that the email account doesn't support push. In that situation, the device does not choose to remain attached to the Wi-Fi network while it is asleep and it is not connected to a power source. (If it is also configured to fetch mail using a periodic schedule, then while it is asleep and it is not connected to a power source, the device will periodically connect to the Wi-Fi network, fetch mail, then disconnect from the Wi-Fi network. Each time it connects, it will perform DHCP to obtain a lease, but that transaction will only happen as often as the device connects to the Wi-Fi network.)