IOS 5.0.1 wireless Bug - DHCP

Question

We discovered an interesting issue yesterday on our network, and upon much searching, I didn't see anyone else with the same conclusion.
Allow me to start by describing the issue.  It's happened on a few occassions in our network over the past several months (we recently started allowing Apple iOS devices on our network as Exchange Activesync clients), but I was finally able to narrow it down today. 
Issue: Certain iOS devices when connected to the wireless network retain their DHCP Lease from their home network in the background, while connecting to the business network with a like subnet.  The IP Address that the iOS device is retaining from home is NOT in the DHCP scope of the business network, but conflicts with a static assigned IP Address on one of the corporate network services (i.e. Print Server, Email Server, File Server, Database Server) in the like subnet.  For example "User A" running an iPhone 4S with iOS 5.0.1 has an Airport Extreme at home that assigns DHCP Addresses in the 10.0.0.x scope.  The Corporate DHCP Scope is 10.0.4.x-10.0.5.x with similar subnet.  "User A" connects to corporate network via wi-fi and is assigned an IP address of 10.0.4.x (but in the background the device is reserving 10.0.0.x from home Airport Extreme.)  Address 10.0.0.x belongs to back-end email server, and whenever "User A" turns their device on, it disrupts the network connectivity for the rest of the corporate network to the email server.  "User A" turns off wi-fi on iPhone, and normal corporate network operations resume.  In the past, the issue has conflicted with a less major server, or another windows client, and so a resolution was able to be acquired by renewing the IP Address on the Windows client computer.
The issue presents it self as one of our Windows Server machines complaining about an IP Address Conflict on the network.  Upon examining the Windows Event Viewer in the System Log, we discover an error message from the "Tcpip" service "The system detected an address conflict for IP address 10.0.0.X with the system having network hardware address 60:C5:47:XX:XX:XX. Network operations on this system may be disrupted as a result." Upon examining the mac address beginning with 60:C5:47 we discover this particular MAC Address range belongs to Apple Inc. (LINK)  This led us to search the building for the offending iOS device on which we were able to verify the Wireless MAC address.
In a similar forum post by a user in 2009, the suggestion was that the issue lay with the Windows computer.  Well, in that particular case, it was a Home PC, and the user was able to 'work-around' the bug by renewing their DHCP lease on their other client that was reporting the issue.  In our case, since the conflict occurs with a Network Server with a staticly assigned IP and services / certificates assigned to that interface, it's not as easy as renewing the IP address to allow the Windows computer to 'fix' the issue.  I believe the issue lies in the iOS wireless driver, and needs to be addressed by Apple Development team.  I'm not sure the best way to accomplish this, so I figured I'd start in the support forum. Since there wasn't a forum for iOS, I placed the issue under iPhone for Enterprise, though this issue is reproducable with iPad and iPod Touch also.
Here's a detailed post by Princeton University where they describe the issue in great detail. http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to-expire-keeps-using- IP-address.html#chronology How can we get greater urgency to get this bug fixed?
I'd appreciate response / suggestions / input / feedback.
Thanks!
DRO4LIFE

Answer 1

This is nothing a feature like DHCP Snooping, IP Source Guard and Dynamic ARP Inspection couldn't resolve.  Why on earth would this be affecting the rest of your network?  If everything is properly segmented, it shouldnt matter if that thing boots up with your e-mail servers IP address.  If it is, you are using a big *** network like a /16 and simply dishing out certain ranges to certain functions rather than using proper subnetting.  I really hope this is not the case as thats a big mistake. 
If you have everything setup properly, I cannot see that device as affecting anything at all;  if it came up with that IP on your wireless subnet, no devices in other subnets should ever be trying to talk to that thing since that IP range is supposed to be reachable elsewhere, like your server subnet, not the wireless subnet.  Your other networks will always be forwarding traffic for your server to your server subnet, never to the wireless subnet.
If you are at all confused about what I am saying, let me ask you this.  What is the default gateway for your Wireless devices and what is the default gateway for your Servers?  If that answer is the same, there lies your problem.  Hire a network engineer to clean up that mess.  If it is not the same, then something like proxy ARP must be turned on since that incorrect IP should not affect anything other than itself with proper layer 3 boundaries.
If that is not an option, you should be able to use a combination of DHCP Snooping,IP Source Guard and Dynamic ARP Inspection to nip this problem in the butt if your running Cisco gear (if other gear, cross reference, I'm sure the feature exists with another name).  The only way for it to cause havok is if the offending device is producing an ARP reply for your servers IP.  If running Dynamic ARP Inspection, it should see the offender responding with an ARP for your servers IP which doesnt match what the DHCP snooping database has in it, and it will drop that ARP reply.  If by chance that offending device did try to transmit as your servers IP, IP Source Guard's dynamic PACL should have dropped that traffic since its source IP does not match what is in the DHCP Snooping database.
I am not doubting that a bug exists here, however a robust network infrastructure would not be affected by what you describe.  Those switch features were designed to halt malicious actions, whether performed intentionally or accidentally via a bug.  A network engineer worth his/her salt would have implemented that in their design.