idnits 2.17.1 draft-perreault-sunset4-noipv4-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3909 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 436 == Missing Reference: 'DHCPv6' is mentioned on line 479, but not defined == Missing Reference: 'DHCPv4' is mentioned on line 481, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Perreault 3 Internet-Draft Viagenie 4 Intended status: Standards Track W. George 5 Expires: January 16, 2014 Time Warner Cable 6 T. Tsou 7 Huawei Technologies (USA) 8 T. Yang 9 L. Li 10 China Mobile 11 July 15, 2013 13 Turning off IPv4 Using DHCPv6 or Router Advertisements 14 draft-perreault-sunset4-noipv4-03 16 Abstract 18 This memo defines a new DHCPv6 option and a new Router Advertisement 19 option for indicating to a dual-stack host or router that IPv4 is to 20 be turned off. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 16, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. The Problems We're Trying to Fix . . . . . . . . . . . . . . 4 59 3.1. Load on DHCPv4 Server . . . . . . . . . . . . . . . . . . 4 60 3.2. Bandwidth Consumption . . . . . . . . . . . . . . . . . . 4 61 3.3. Power Inefficiency . . . . . . . . . . . . . . . . . . . 4 62 3.4. IPv4 only Applications . . . . . . . . . . . . . . . . . 4 63 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 4 64 4.1. DHCPv6 vs DHCPv4 . . . . . . . . . . . . . . . . . . . . 4 65 4.2. DHCPv6 vs RA . . . . . . . . . . . . . . . . . . . . . . 5 66 5. The No-IPv4 Option . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. DHCPv6 Wire Format . . . . . . . . . . . . . . . . . . . 6 68 5.2. RA Wire Format . . . . . . . . . . . . . . . . . . . . . 6 69 5.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 9.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Appendix A. Test Results of Terminals Behavior . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 When a dual-stack host makes a DHCPv4 request, it typically 83 interprets the absence of a response as a failure condition. This 84 makes it difficult to deploy such nodes in an IPv6-only network. 86 Take for example a home router that is dual-stack capable but 87 provisioned with an IPv6-only WAN connection. When the router boots, 88 it typically assigns an IPv4 address to its LAN interface, starts 89 services on that interface, and starts handing out IPv4 addresses to 90 clients on the LAN by answering DHCPv4 requests. This is done 91 unconditionally, without taking the status of the IPv4 connectivity 92 on the WAN interface into account. Hosts on the LAN, in turn, 93 install a default route pointing to the router and start behaving as 94 if IPv4 connectivity was available. IPv4 packets destined to the 95 Internet get dropped at the router and timeouts happen. The end 96 result is that IPv4 remains fully active on the LAN and on the router 97 itself even when it is desired that it be turned off. 99 The other exmaple is about DHCPv4 server. In Dual-Stack LAN/WLAN 100 network or intranet, the core router or AC often plays the role of 101 DHCP server, and the clients are server thousands PC or mobile 102 phones. If the server is configured in IPv6-only, the dual-stack or 103 IPv4-only clients will broadcast DHCPDISCOVER messages endlessly in 104 the LAN or WLAN. The thousands clients will cause a DDOS-like attack 105 to all the servers in the network. Since there are not specific 106 descriptions in any RFCs for client's behavior when it does not 107 receive the DHCPOFFER in response to its DHCPDISCOVER message, 108 various OS deploy different backoff algorithms. We tested server 109 popuplar OS(es), the test results is listed in the appendix. 111 A new mechanism is needed to indicate the absence of IPv4 112 connectivity or service that the goal is turning off IPv4, this new 113 signaling mechanism shall be transported over IPv6. Therefore, we 114 introduce a new DHCPv6 [RFC3315] option and a new Router 115 Advertisement (RA) [RFC4861] option for the purpose of explicitly 116 indicating to the host that IPv4 connectivity is unavailable. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 The following terms are also used in this document: 126 Upstream Interface: An interface on which the No-IPv4 option is 127 received over either DHCPv6 or RA. 129 3. The Problems We're Trying to Fix 131 3.1. Load on DHCPv4 Server 133 When a DHCPv4 server is present but intentionally does not respond to 134 a dual-stack node, the aggregated traffic generated by multiple such 135 dual-stack nodes can represent a significant useless load. This 136 scenario can be encountered for example with an ISP serving multiple 137 types of subscribers where some will get IPv4 addresses and others 138 not. It might not be feasible for operational reasons to block the 139 useless requests before they reach the DHCPv4 server, e.g. if the 140 DHCPv4 server itself is the one that has knowledge about which node 141 should or should not get an IPv4 address. 143 3.2. Bandwidth Consumption 145 In addition to useless load on the DHCPv4 server, the above scenario 146 could also consume a significant amount of bandwidth, particularly if 147 the aggregated traffic from many clients goes through a low-bandwidth 148 link. 150 3.3. Power Inefficiency 152 A dual-stack node that does not get a DHCPv4 response will usually 153 continue retransmitting forever. Therefore, only providing IPv6 on a 154 link will cause the node to needlessly wake up periodically and 155 transmit a few packets. For example, the popular DHCPv4 client 156 implementation by ISC wakes up every 5 minutes by default and tries 157 to contact a DHCPv4 server for 60 seconds. With this configuration, 158 a node will not be able to sleep 20% of the time. 160 3.4. IPv4 only Applications 162 In many cases, IPv4-only applications such as Skype use IPv4 LLA to 163 bombard the LAN with IPv4 packets. In an IPv6-only environment, it 164 can get quite annoying and waste a lot of bandwidth. 166 4. Design Considerations 168 4.1. DHCPv6 vs DHCPv4 170 NOTE: This section will be removed before publication as an RFC. 172 This document describes a new DHCPv6 option for turning off IPv4. An 173 equivalent option could conceivably be created for DHCPv4. Here is a 174 discussion of the pros and cons. Arguments with a + sign argue for a 175 DHCPv4 option, arguments with a - sign argue against. 177 + Devices that don't speak IPv6 won't be listening for a "turn off 178 IPv4" code, and therefore won't stop trying to establish IPv4 179 connectivity. 181 - Devices that haven't been updated to speak IPv6 likely won't 182 recognize a new DHCPv4 code telling them that IPv4 isn't 183 supported. 185 + However, it's easier to implement something that 186 turns off the IP stack than implement IPv6. 188 - Devices that don't speak IPv6 that are still active on the network 189 mean that either IPv4 can't/shouldn't be turned off yet, or IPv4 190 local connectivity should be maintained to retain local services, 191 even if global IPv4 connectivity is not necessary (think local LAN 192 DLNA streaming, etc). 194 - When the goal is to turn off IPv4, having to maintain and operate 195 an IPv4 infrastructure (routing, ACLs, etc.) just to be able to 196 send negative responses to DHCPv4 requests is not productive. 197 Having the option transported in IPv6 allows the ISP to focus on 198 operating an IPv6-only network. 200 + However, a full IPv4 infrastructure would not be necessary 201 in many cases. The local router could contain a very 202 restricted DHCPv4 server function whose only purpose would 203 be to reply with the No-IPv4 option. No IPv4 traffic would 204 have to be carried to a distant DHCPv4 server. Note however 205 that this may not be operationally feasible in some 206 situations. 208 - Turning IPv4 off using an IPv4-transported signal means that there 209 is no way to go back. Once the DHCPv4 option has been accepted by 210 the DHCPv4 client, IPv4 can no longer be turned on remotely 211 (rebooting the client still works). Configurations change, 212 mistakes happen, and so it is necessary to have a way to turn IPv4 213 back on. With a DHCPv6 option, IPv4 can be turned back on as soon 214 as the client makes a new DHCPv6 request, which can be the next 215 scheduled one or can be triggered immediately with a Reconfigure 216 message. 218 The authors conclude that a DHCPv6 option is clearly necessary, 219 whereas it is not as clear for a DHCPv4 option. More feedback on 220 this topic would be appreciated. 222 4.2. DHCPv6 vs RA 223 Both DHCPv6- and RA-based solutions are presented in this draft. It 224 is expected that the working group will decide whether both 225 solutions, only one, or none are desirable. 227 5. The No-IPv4 Option 229 The No-IPv4 DHCPv6 option is used to signal the unavailability of 230 IPv4 connectivity. 232 5.1. DHCPv6 Wire Format 234 The format of the DHCPv6 No-IPv4 option is: 236 0 1 2 3 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | OPTION_NO_IPV4 | option-len | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | v4-level | 242 +-+-+-+-+-+-+-+-+ 244 option-code OPTION_NO_IPV4 (TBD). 246 option-len 1. 248 v4-level Level of IPv4 functionality. 250 The DHCPv6 client MUST place the OPTION_NO_IPV4 option code in the 251 Option Request Option ([RFC3315] section 22.7). Servers MAY include 252 the option in responses (if they have been so configured). Servers 253 MAY also place the OPTION_NO_IPV4 option code in an Option Request 254 Option contained in a Reconfigure message. 256 5.2. RA Wire Format 258 The format of the RA No-IPv4 option is: 260 0 1 2 3 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | v4-level | Reserved | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Reserved | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Type TBD 269 Length 1. 271 v4-level Level of IPv4 functionality. 273 Reserved These fields are unused. They MUST be initialized 274 to zero by the sender and MUST be ignored by the 275 receiver. 277 5.3. Semantics 279 The option applies to the link on which it is received. It is used 280 to indicate to the client that it should disable some or all of its 281 IPv4 functionality. What should be disabled depends on the value of 282 v4-level. 284 v4-level can take the following values: 286 0 - IPv4 fully enabled: This is equivalent to the absence of the No- 287 IPv4 option. It is included here so that a DHCPv6 server can 288 explicitly re-enable IPv4 access by including it in a Reply 289 message following a Reconfigure, or similarly by a router in a 290 spontaneous Router Advertisement. 292 1 - No IPv4 upstream: Any kind of IPv4 connectivity is unavailable 293 on the link on which the option is received. Therefore, any 294 attempts to provision IPv4 by the host or to use IPv4 in any 295 fashion, on that link, will be useless. IPv4 MAY be dropped, 296 blocked, or otherwise ignored on that link. 298 Upon reception of the No-IPv4 option with value 1, the following 299 IPv4 functionality MUST be disabled on the Upstream Interface: 301 a. IPv4 addresses MUST NOT be assigned. 303 b. Currently-assigned IPv4 addresses MUST be unassigned. 305 c. Dynamic configuration of link-local IPv4 addresses [RFC3927] 306 MUST be disabled. 308 d. IPv4, ICMPv4, or ARP packets MUST NOT be sent. 310 e. IPv4, ICMPv4, or ARP packets received MUST be ignored. 312 f. DNS A queries MUST NOT be sent, even transported over IPv6. 314 2 - No IPv4 upstream, local IPv4 restricted: Same semantics as value 315 1, with the following additions: 317 If all DHCPv6- or RA-configured interfaces receive the No-IPv4 318 option with a mix of values 1, 2, and 3 (but not exclusively 3), 319 and no other interface provides IPv4 connectivity to the Internet, 320 IPv4 is partially shut down, leaving only local connectivity 321 active. On the Upstream Interface, IPv4 MUST be shut down as 322 listed above. On other interfaces, IPv4 addresses MUST NOT be 323 assigned except for the following: 325 * Loopback (127.0.0.0/8) 327 * Link Local (169.254.0.0/16) [RFC3927] 329 * Private-Use (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) 330 [RFC1918] 332 3 - No IPv4 at all: This is intended to be a stricter version of the 333 above. 335 The host or router receiving this option MUST disable IPv4 336 functionality on the Upstream Interface in the same way as for 337 value 1 or 2. 339 If all DHCPv6- or RA-configured interfaces received the No-IPv4 340 option with exclusively value 3, and no other interface provides 341 IPv4 connectivity to the Internet, IPv4 is completely shut down. 342 In particular: 344 a. IPv4 address MUST NOT be assigned to any interface. 346 b. Currently-assigned IPv4 addresses MUST be unassigned. 348 c. Dynamic configuration of link-local IPv4 addresses [RFC3927] 349 MUST be disabled. 351 d. IPv4, ICMPv4, or ARP packets MUST NOT be sent on any 352 interface. 354 e. IPv4, ICMPv4, or ARP packets received on any interface MUST be 355 ignored. 357 f. In the above, "any interface" includes loopback interfaces. 358 In particular, the 127.0.0.1 special address MUST be removed. 360 g. Server programs listening on IPv4 addresses (e.g., a DHCPv4 361 server) MAY be shut down. 363 h. DNS A queries MUST NOT be sent, even transported over IPv6. 365 i. If the host or router also runs a DHCPv6 server, it SHOULD 366 include the No-IPv4 option with value 2 in DHCPv6 responses it 367 sends to clients that request it, unless prohibited by local 368 policy. If it currently has active clients, it SHOULD send a 369 Reconfigure to each of them with the OPTION_NO_IPV4 included 370 in the Option Request Option. 372 j. If the router sends Router Advertisement, it SHOULD include 373 the No-IPv4 option with value 2 in RA messages it sends, 374 unless prohibited by local policy. It SHOULD also send RAs 375 immediately so that the changes take effect for all current 376 hosts. 378 The intent is to remove all traces of IPv4 activity. Once the No- 379 IPv4 option with value 3 is activated, the network stack should 380 behave as if IPv4 functionality had never been present. For 381 example, a modular kernel implementation could accomplish the 382 above by unloading the IPv4 kernel module at run time. 384 5.4. Example 386 A dual-stack home gateway is set up with a single WAN uplink and is 387 configured to use DHCPv4 and DHCPv6 to automatically obtain IPv4 and 388 IPv6 connectivity. On the LAN side, it has one link with multiple 389 hosts. 391 When it boots, the router assigns 192.168.1.1/24 to its LAN 392 interfaces and starts a DHCPv4 server listening on it. It hands out 393 addresses 191.168.1.100-199 to clients. It also starts an IPv6 394 Router Advertisement daemon as well as a stateless DHCPv6 server, 395 also listening on the LAN interfaces. 397 On the WAN side, it starts two provisioning procedures in parallel: 398 one for IPv4 and one for IPv6. 400 At this point, the ISP does not know if the router supports IPv6-only 401 operation. Therefore, by default, the ISP responds to DHCPv4 402 requests as usual. 404 As part of the IPv6 provisioning procedure, the router sends a DHCPv6 405 request containing OPTION_NO_IPV4 in an Option Request Option. The 406 ISP's DHCPv6 server's reply includes the No-IPv4 option with value 3. 407 When this procedure finishes, the ISP has determined that this 408 customer will run in IPv6-only mode and starts dropping all IPv4 409 packets at the first hop. If an IPv4 address was assigned, it is 410 reclaimed, and possibly reassigned to another subscriber. 412 The home router aborts the IPv4 provisioning procedure (if it is 413 still running) and deactivates all IPv4 functionality. It shuts down 414 its DHCPv4 server. It also configures its own stateless DHCPv6 415 server to send the No-IPv4 option to clients that request it. 417 As an optimization, the router could delay setting up IPv4 by a few 418 seconds (10 seconds seems reasonable). If the IPv6 procedure 419 completes with the No-IPv4 option during that time, IPv4 will never 420 have been set up and the router will operate in pure IPv6-only mode 421 from the start. 423 6. Security Considerations 425 One security concern is that an attacker could use the No-IPv4 option 426 to deny IPv4 access to a victim. However, unprotected vanilla DHCP 427 can already be exploited to cause such a denial of service ([RFC2131] 428 section 7). 430 TO BE COMPLETED 432 7. IANA Considerations 434 IANA is requested to assign value TBD with description OPTION_NO_IPV4 435 in the "DHCP Option Codes" table which is part of the 436 dhcpv6-parameters registry [1]. 438 IANA is requested to assign value TBD with description "No-IPv4 439 Option" in the IPv6 Neighbor Discovery Option Formats table which is 440 part of the icmpv6-parameters registry. 442 8. Acknowledgements 444 Thanks in particular to Marc Blanchet who was the driving force 445 behind this work. 447 Rajiv Asati contributed section Section 3.4. 449 9. References 451 9.1. Normative References 453 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 454 E. Lear, "Address Allocation for Private Internets", BCP 455 5, RFC 1918, February 1996. 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 461 and M. Carney, "Dynamic Host Configuration Protocol for 462 IPv6 (DHCPv6)", RFC 3315, July 2003. 464 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 465 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 466 2005. 468 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 469 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 470 September 2007. 472 9.2. Informative References 474 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 475 2131, March 1997. 477 Appendix A. Test Results of Terminals Behavior 479 In RFC3315 [RFC3315, DHCPv6], SOL_MAX_RT is defined in DHCPv6 to 480 prevent the frequently requesting of clients, which reduces the 481 aggregated traffic. But in RFC2131 [RFC2131, DHCPv4], there are not 482 corresponding IPv4 definitions or options for client's behavior if 483 the server does not respond for the Discover messages. 485 In fact, most of the terminals creat backoff algorithms to help them 486 retransmit DHCPDISCOVER message in different frequency according to 487 their state machine. The same point of almost all the verious 488 Operating Systems is that they could not stop DHCPDISCOVER requests 489 to the server. And that will cause DDoS-Like attack to the server 490 and bandwidth consumption in the link. 492 We test some of the most popular terminals' OS in WLAN, the results 493 are illuminated as below. 495 -------------------------------------------------------------------- 496 DHCP Discovery Packages Time Table 497 -------------------------------------------------------------------- 498 | Windows7 |Windows XP | IOS_5.0.1 |Android_2.3.7|Symbian_S60 499 No|Time | Time | Time | Time |Time | Time |Time | Time |Time| Time 500 | |offset| |offset| |offset| |offset | |offset 501 --|-----|------|------|------|-----|------|-----|-------|----|------ 502 1 |0 | |0 | |0.1 | |7.8 | |0 | 503 2 |3.9 |3.9 |0.1 | 0.1 |1.4 | 1.3 |10.3 | 2.5 |2 | 2 504 3 |13.3 |9.4 |4.1 | 4 |3.8 | 2.4 |17.9 | 7.6 |6 | 4 505 4 |30.5 |17.2 |12.1 | 8 |7.9 | 4.1 |33.9 | 16 |8 | 2 506 5 |62.8 |32.3 |29.1 | 17 |16.3 | 8.4 |36.5 | 2.6 |12 | 4 507 6 |65.9 |3.1 |64.9 | 35.8 |24.9 | 8.6 | reconnect |14 | 2 508 7 |74.9 |9 |68.9 | 4 |33.4 | 8.5 |56.6 | 20.1 |18 | 4 509 8 |92.1 |17.2 |77.9 | 9 |42.2 | 8.8 |60.2 | 3.6 |20 | 2 510 9 |395.2|303.1 |93.9 | 16 |50.8 | 8.6 |68.4 | 8.2 |24 | 4 511 10|399.1|3.9 |433.9 | 340 |59.1 | 8.3 |84.8 | 16.4 |26 | 2 512 11|407.1|8 |438.9 | 5 |127.3| 68.2|86.7 | 1.9 |30.1| 4.1 513 12|423.4|16.3 |447.9 | 9 |128.9| 1.6 | reconnect |32.1| 2 514 13|455.4|32 |464.9 | 17 |131.1| 2.2 |106.7| 20 |36.1| 4 515 14|460.4|5 |794.9 | 330 |135.1| 4 |111.4| 4.7 |38.1| 2 516 15|467.4|7 |799.9 | 5 |143.4| 8.3 |120.6| 9.2 |42.1| 4 517 16|483.4|16 |808.9 | 9 |151.7| 8.3 |134.9| 14.3 |44.1| 2 518 17|842.9|359.5 |824.9 | 16 |160.4| 8.7 |136.8| 1.9 |48.2| 4.1 519 18|846.9|4 |1141.9| 317 |168.8| 8.4 | reconnect |50.2| 2 520 -------------------------------------------------------------------- 522 Figure:Terminals DHCPDISCOVER requests when Server's DHCPv4 module is 523 down 525 In this figure: 527 For Windows7, it seems to initiate 8 times DHCPDISCOVER requests in 528 about 300s interval. 530 For WindowsXP, firstly it launches 9 times DHCPDISCOVER messages, but 531 after that it cannot get any response from the server, then it 532 initiates 5 times requests in one cycle in around 330s intervals, and 533 never stop. 535 For IOS5.0.1, it seems like WindowsXP. There are 10 times attempts 536 in one cycle, and the interval is about 68s. 538 Symbian_S60 uses the simplest backoff method, it launches DISCOVER in 539 every 2 or 4 seconds. 541 Android2.3.7 is the only Operating System which can stop DISCOVER 542 request by disconnect its wireless connection. It reboot wireless 543 and dhcp connection every 20 seconds. 545 Authors' Addresses 546 Simon Perreault 547 Viagenie 548 246 Aberdeen 549 Quebec, QC G1R 2E1 550 Canada 552 Phone: +1 418 656 9254 553 Email: simon.perreault@viagenie.ca 554 URI: http://viagenie.ca 556 Wes George 557 Time Warner Cable 558 13820 Sunrise Valley Drive 559 Herndon, VA 20171 560 USA 562 Email: wesley.george@twcable.com 564 Tina Tsou 565 Huawei Technologies (USA) 566 2330 Central Expressway 567 Santa Clara, CA 95050 568 USA 570 Phone: +1 408 330 4424 571 Email: tina.tsou.zouting@huawei.com 573 Tianle Yang 574 China Mobile 575 32, Xuanwumenxi Ave. 576 Xicheng District, Beijing 100053 577 China 579 Email: yangtianle@chinamobile.com 581 Li Lianyuan 582 China Mobile 583 32, Xuanwumenxi Ave. 584 Xicheng District, Beijing 100053 585 China 587 Email: lilianyuan@chinamobile.com