[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-perreault-sunset4-noipv4) 00 01

Network Working Group                                       S. Perreault
Internet-Draft                                       Jive Communications
Intended status: Standards Track                               W. George
Expires: June 7, 2015                                  Time Warner Cable
                                                                 T. Tsou
                                               Huawei Technologies (USA)
                                                                 T. Yang
                                                                   L. Li
                                                            China Mobile
                                                            JF. Tremblay
                                                                Viagenie
                                                        December 4, 2014


         Turning off IPv4 Using DHCPv6 or Router Advertisements
                      draft-ietf-sunset4-noipv4-01

Abstract

   This memo defines a new DHCPv6 option and a new Router Advertisement
   option to inform a dual-stack host or router that IPv4 can be turned
   off.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 7, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Perreault, et al.         Expires June 7, 2015                  [Page 1]


Internet-Draft                   No IPv4                   December 2014


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problems Being Addressed  . . . . . . . . . . . . . . . . . .   3
     3.1.  Load on DHCPv4 Server and Relay . . . . . . . . . . . . .   4
     3.2.  Bandwidth Consumption . . . . . . . . . . . . . . . . . .   4
     3.3.  Power Inefficiency  . . . . . . . . . . . . . . . . . . .   4
     3.4.  IPv4 Only Applications  . . . . . . . . . . . . . . . . .   4
   4.  Design Considerations . . . . . . . . . . . . . . . . . . . .   4
     4.1.  DHCPv6 vs DHCPv4  . . . . . . . . . . . . . . . . . . . .   4
     4.2.  DHCPv6 vs RA  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  The No-IPv4 DHCPv6 Option . . . . . . . . . . . . . . . . . .   6
     5.1.  DHCPv6 Wire Format  . . . . . . . . . . . . . . . . . . .   6
     5.2.  RA Wire Format  . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Semantics . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.4.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Appendix A.  Test Results of Terminals Behavior . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   When a dual-stack host makes a DHCPv4 request, it typically
   interprets the absence of a response as a failure condition.  This
   may cause operational problems when deploying an IPv6-only network.
   Providing a way to inform hosts and routers that IPv4 is not
   available would prevent such problems and allow for smoother
   deployments.

   One situation where problems arise is with a dual-stack home router
   provisioned with an IPv6-only WAN connection.  It typically assigns
   an IPv4 address to its LAN interface, starts services on that
   interface and hands out IPv4 addresses to clients on the LAN by
   answering DHCPv4 requests.  This is done unconditionally, without



Perreault, et al.         Expires June 7, 2015                  [Page 2]


Internet-Draft                   No IPv4                   December 2014


   taking the status of the IPv4 connectivity on the WAN interface into
   account.  Hosts on the LAN install a default route pointing to the
   router and behave as if IPv4 connectivity was available.  IPv4
   packets destined to the Internet get dropped at the router and
   timeouts happen.  The end result is that IPv4 remains fully active on
   the LAN and on the router itself even if it would be desirable to
   turn it off, especially for applications that do not implement Happy
   Eyeballs [RFC6555].

   Another situation relates to the load on DHCPv4 servers and relays.
   In large dual-stack network (LAN, WLAN), thousands of hosts,
   including mobile phones, may generate a significant amount of trafic
   by attempting to contact a DHCP server.  If the servers and relays
   are configured in IPv6-only, the dual-stack or IPv4-only clients will
   broadcast DHCPDISCOVER messages endlessly, creating a DDOS-like
   attack on the network.  This scenario has also been briefly described
   for DHCPv6 in [RFC7083].  Although DHCP mandates a exponential
   backoff, it is limited to 64 seconds, which may still generate
   significant traffic (see section 4.1 of [RFC2131]).  Various
   operating systems also implement the backoff algorithms in different
   ways, or not at all, with different limit values.  Some test results
   for a few popular operating systems are available in appendix.

   A new mechanism is needed to indicate the absence of IPv4
   connectivity.  Considering the end goal is turn off all IPv4
   connectivity, the chosen mechanism should be transported over IPv6.
   Therefore, this document introduce a new DHCPv6 [RFC3315] option and
   a new Router Advertisement (RA) [RFC4861] option for the purpose of
   explicitly indicating to the host that IPv4 connectivity is
   unavailable.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The following terms are also used in this document:

   Upstream Interface:  An interface on which the No-IPv4 option is
      received over either DHCPv6 or RA.

3.  Problems Being Addressed








Perreault, et al.         Expires June 7, 2015                  [Page 3]


Internet-Draft                   No IPv4                   December 2014


3.1.  Load on DHCPv4 Server and Relay

   When a DHCPv4 server or relay is present but intentionally does not
   react to DHCPDISCOVERs, the aggregated traffic generated by a large
   number of dual-stack hosts can represent a significant bandwidth
   load.  This scenario is encountered with an ISP serving multiple
   types of subscribers where some a provisioned for IP4 service and
   others are not.  It might not be feasible for operational reasons to
   block the useless requests before they reach the DHCPv4 servers, for
   example if the DHCPv4 servers themselves are the only ones with the
   knowledge of which nodes should or should not get an IPv4 address.

3.2.  Bandwidth Consumption

   In addition to the useless load on the DHCPv4 servers, the above
   scenario could also consume a significant amount of bandwidth,
   especially if the aggregated traffic from many clients goes through a
   low-bandwidth link or through a wireless link.

3.3.  Power Inefficiency

   A dual-stack node that does not get a DHCPv4 response will usually
   continue retransmitting forever.  Therefore, only providing IPv6 on a
   link will cause the node to needlessly wake up periodically and
   transmit a few packets.  For example, the popular DHCPv4 client
   implementation by ISC wakes up every 5 minutes by default and tries
   to contact a DHCPv4 server for 60 seconds.  With this configuration,
   a node will not be able to sleep 20% of the time.

3.4.  IPv4 Only Applications

   In many cases, IPv4-only applications such as Skype use an
   autoconfigured IPv4 Link-Local Addresses (LLA) to send IPv4 packets
   on the LAN.  In an IPv6-only environment, this behavior may waste a
   significant amount of bandwidth.

4.  Design Considerations

4.1.  DHCPv6 vs DHCPv4

      NOTE: This section will be removed before publication as an RFC.

   This document describes a new DHCPv6 option to turn off IPv4.  An
   equivalent option could conceivably be created for DHCPv4.  The pros
   and cons are discussed below.  Arguments with a + sign argue for a
   DHCPv4 option, arguments with a - sign argue against.





Perreault, et al.         Expires June 7, 2015                  [Page 4]


Internet-Draft                   No IPv4                   December 2014


   +  Devices that don't speak IPv6 won't be listening for a "turn off
      IPv4" code, and therefore won't stop trying to establish IPv4
      connectivity.

      -  Devices that haven't been updated to speak IPv6 likely won't
         recognize a new DHCPv4 code telling them that IPv4 isn't
         supported.

         +  However, it's easier to implement something that turns off
            the IP stack than implement IPv6.

   -  Devices that don't speak IPv6 that are still active on the network
      mean that either IPv4 can't/shouldn't be turned off yet, or IPv4
      local connectivity should be maintained to retain local services,
      even if global IPv4 connectivity is not necessary (think local LAN
      DLNA streaming, etc).

   -  When the goal is to turn off IPv4, having to maintain and operate
      an IPv4 infrastructure (routing, ACLs, etc.) just to be able to
      send negative responses to DHCPv4 requests is not productive.
      Having the option transported in IPv6 allows the ISP to focus on
      operating an IPv6-only network.

      +  However, a full IPv4 infrastructure would not be necessary in
         many cases.  The local router could contain a very restricted
         DHCPv4 server function whose only purpose would be to reply
         with the No-IPv4 option.  No IPv4 traffic would have to be
         carried to a distant DHCPv4 server.  Note however that this may
         not be operationally feasible in some situations.

   -  Turning IPv4 off using an IPv4-transported signal means that there
      is no way to go back.  Once the DHCPv4 option has been accepted by
      the DHCPv4 client, IPv4 can no longer be turned on remotely
      (rebooting the client still works).  Configurations change,
      mistakes happen, and so it is necessary to have a way to turn IPv4
      back on.  With a DHCPv6 option, IPv4 can be turned back on as soon
      as the client makes a new DHCPv6 request, which can be the next
      scheduled one or can be triggered immediately with a Reconfigure
      message.

   The authors conclude that a DHCPv6 option is clearly necessary,
   whereas the need for a DHCPv4 option is not as obvious.  More
   feedback on this topic would be appreciated.








Perreault, et al.         Expires June 7, 2015                  [Page 5]


Internet-Draft                   No IPv4                   December 2014


4.2.  DHCPv6 vs RA

   Both DHCPv6 and RA-based solutions are presented in this draft.  It
   is expected that the working group will decide whether both
   solutions, only one, or none are desirable.

5.  The No-IPv4 DHCPv6 Option

   The No-IPv4 DHCPv6 option is used to signal the unavailability of
   IPv4 connectivity.

5.1.  DHCPv6 Wire Format

   The format of the DHCPv6 No-IPv4 option is:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         OPTION_NO_IPV4        |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    v4-level   |
   +-+-+-+-+-+-+-+-+

     option-code     OPTION_NO_IPV4 (TBD).

     option-len      1.

     v4-level        Level of IPv4 functionality.

   The DHCPv6 client MUST place the OPTION_NO_IPV4 option code in the
   Option Request Option ([RFC3315] section 22.7).  Servers MAY include
   the option in responses (if they have been so configured).  Servers
   MAY also place the OPTION_NO_IPV4 option code in an Option Request
   Option contained in a Reconfigure message.

5.2.  RA Wire Format

   The format of the RA No-IPv4 option is:













Perreault, et al.         Expires June 7, 2015                  [Page 6]


Internet-Draft                   No IPv4                   December 2014


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   v4-level    |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type          TBD

     Length        1.

     v4-level      Level of IPv4 functionality.

     Reserved      These fields are unused.  They MUST be initialized
                   to zero by the sender and MUST be ignored by the
                   receiver.

5.3.  Semantics

   The option applies to the link on which it is received.  It is used
   to indicate to the client that it should disable some or all of its
   IPv4 functionality.  What should be disabled depends on the value of
   v4-level.

   v4-level can take the following values:

   0 - IPv4 fully enabled:  This is equivalent to the absence of the No-
      IPv4 option.  It is included here so that a DHCPv6 server can
      explicitly re-enable IPv4 access by including it in a Reply
      message following a Reconfigure, or similarly by a router in a
      spontaneous Router Advertisement.

   1 - No IPv4 upstream:  Any kind of IPv4 connectivity is unavailable
      on the link on which the option is received.  Therefore, any
      attempts to provision IPv4 by the host or to use IPv4 in any
      fashion, on that link, will be useless.  IPv4 MAY be dropped,
      blocked, or otherwise ignored on that link.

      Upon reception of the No-IPv4 option with value 1, the following
      IPv4 functionality MUST be disabled on the Upstream Interface:

      A.  IPv4 addresses MUST NOT be assigned.

      B.  Currently-assigned IPv4 addresses MUST be unassigned.

      C.  Dynamic configuration of link-local IPv4 addresses [RFC3927]
          MUST be disabled.



Perreault, et al.         Expires June 7, 2015                  [Page 7]


Internet-Draft                   No IPv4                   December 2014


      D.  IPv4, ICMPv4, or ARP packets MUST NOT be sent.

      E.  IPv4, ICMPv4, or ARP packets received MUST be ignored.

      F.  DNS A queries MUST NOT be sent, even transported over IPv6.

   2 - No IPv4 upstream, local IPv4 restricted:  Same semantics as value
      1, with the following additions:

      If all DHCPv6- or RA-configured interfaces receive the No-IPv4
      option with a mix of values 1, 2, and 3 (but not exclusively 3),
      and no other interface provides IPv4 connectivity to the Internet,
      IPv4 is partially shut down, leaving only local connectivity
      active.  On the Upstream Interface, IPv4 MUST be shut down as
      listed above.  On other interfaces, IPv4 addresses MUST NOT be
      assigned except for the following:

      *  Loopback (127.0.0.0/8)

      *  Link Local (169.254.0.0/16) [RFC3927]

      *  Private-Use (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
         [RFC1918]

   3 - No IPv4 at all:  This is intended to be a stricter version of the
      above.

      The host or router receiving this option MUST disable IPv4
      functionality on the Upstream Interface in the same way as for
      value 1 or 2.

      If all DHCPv6 or RA-configured interfaces received the No-IPv4
      option with value 3, and no other interface provides IPv4
      connectivity to the Internet, IPv4 is completely shut down.  In
      particular:

      A.  IPv4 address MUST NOT be assigned to any interface.

      B.  Currently-assigned IPv4 addresses MUST be unassigned.

      C.  Dynamic configuration of link-local IPv4 addresses [RFC3927]
          MUST be disabled.

      D.  IPv4, ICMPv4, or ARP packets MUST NOT be sent on any
          interface.

      E.  IPv4, ICMPv4, or ARP packets received on any interface MUST be
          ignored.



Perreault, et al.         Expires June 7, 2015                  [Page 8]


Internet-Draft                   No IPv4                   December 2014


      F.  In the above, "any interface" includes loopback interfaces.
          In particular, the 127.0.0.1 special address MUST be removed.

      G.  Server programs listening on IPv4 addresses (e.g., a DHCPv4
          server) MAY be shut down.

      H.  DNS A queries MUST NOT be sent, even transported over IPv6.

      I.  If the host or router also runs a DHCPv6 server, it SHOULD
          include the No-IPv4 option with value 2 in DHCPv6 responses it
          sends to clients that request it, unless prohibited by local
          policy.  If it currently has active clients, it SHOULD send a
          Reconfigure to each of them with the OPTION_NO_IPV4 included
          in the Option Request Option.

      J.  If the router sends Router Advertisement, it SHOULD include
          the No-IPv4 option with value 2 in RA messages it sends,
          unless prohibited by local policy.  It SHOULD also send RAs
          immediately so that the changes take effect for all current
          hosts.

      The intent is to remove all traces of IPv4 activity.  Once the No-
      IPv4 option with value 3 is activated, the network stack should
      behave as if IPv4 functionality had never been present.  For
      example, a modular kernel implementation could accomplish the
      above by unloading the IPv4 kernel module at run time.

5.4.  Example

   A dual-stack home gateway is set up with a single WAN uplink and is
   configured to use DHCPv4 and DHCPv6 to automatically obtain IPv4 and
   IPv6 connectivity.  On the LAN side, it has one link with multiple
   hosts.

   When it boots, the router assigns 192.168.1.1/24 to its LAN
   interfaces and starts a DHCPv4 server listening on it.  It hands out
   addresses 191.168.1.100-199 to clients.  It also starts an IPv6
   Router Advertisement daemon as well as a stateless DHCPv6 server,
   also listening on the LAN interfaces.

   On the WAN side, it starts two provisioning procedures in parallel:
   one for IPv4 and one for IPv6.

   At this point, the ISP does not know if the router supports IPv6-only
   operation.  Therefore, by default, the ISP responds to DHCPv4
   requests as usual.





Perreault, et al.         Expires June 7, 2015                  [Page 9]


Internet-Draft                   No IPv4                   December 2014


   As part of the IPv6 provisioning procedure, the router sends a DHCPv6
   request containing OPTION_NO_IPV4 in an Option Request Option.  The
   ISP's DHCPv6 server's reply includes the No-IPv4 option with value 3.
   When this procedure finishes, the ISP has determined that this
   customer will run in IPv6-only mode and starts dropping all IPv4
   packets at the first hop.  If an IPv4 address was assigned, it is
   reclaimed, and possibly reassigned to another subscriber.

   The home router aborts the IPv4 provisioning procedure (if it is
   still running) and deactivates all IPv4 functionality.  It shuts down
   its DHCPv4 server.  It also configures its own stateless DHCPv6
   server to send the No-IPv4 option to clients that request it.  (JFT:
   What happens if the timer below is not implemented and IPv4 completes
   before IPv6?  Maybe we could recommend to run IPv6 provisioning first
   when OPTION_NO_IPV4 is supported.)

   As an optimization, the router could delay setting up IPv4 by a few
   seconds (10 seconds seems reasonable).  If the IPv6 procedure
   completes with the No-IPv4 option during that time, IPv4 will never
   have been set up and the router will operate in pure IPv6-only mode
   from the start.

6.  Security Considerations

   One security concern is that an attacker could use the No-IPv4 option
   to deny IPv4 access to a victim.  However, unprotected vanilla DHCP
   can already be exploited to cause such a denial of service ([RFC2131]
   section 7).

   TO BE COMPLETED

7.  IANA Considerations

   IANA is requested to assign value TBD with description OPTION_NO_IPV4
   in the "DHCP Option Codes" table which is part of the
   dhcpv6-parameters registry [1].

   IANA is requested to assign value TBD with description "No-IPv4
   Option" in the IPv6 Neighbor Discovery Option Formats table which is
   part of the icmpv6-parameters registry.

8.  Acknowledgements

   Thanks in particular to Marc Blanchet who was the driving force
   behind this work.

   Rajiv Asati contributed section Section 3.4.




Perreault, et al.         Expires June 7, 2015                 [Page 10]


Internet-Draft                   No IPv4                   December 2014


9.  References

9.1.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets", BCP
              5, RFC 1918, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927, May
              2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

9.2.  Informative References

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, April 2012.

   [RFC7083]  Droms, R., "Modification to Default Values of SOL_MAX_RT
              and INF_MAX_RT", RFC 7083, November 2013.

9.3.  URIs

   [1] http://www.iana.org/assignments/dhcpv6-parameters

Appendix A.  Test Results of Terminals Behavior

   In RFC3315 [RFC3315, DHCPv6], SOL_MAX_RT is defined in DHCPv6 to
   prevent the frequently requesting of clients, which reduces the
   aggregated traffic.  But in RFC2131 [RFC2131, DHCPv4], there are not
   corresponding IPv4 definitions or options for client's behavior if
   the server does not respond for the Discover messages.

   In fact, most of the terminals creat backoff algorithms to help them
   retransmit DHCPDISCOVER message in different frequency according to



Perreault, et al.         Expires June 7, 2015                 [Page 11]


Internet-Draft                   No IPv4                   December 2014


   their state machine.  The same point of almost all the verious
   Operating Systems is that they could not stop DHCPDISCOVER requests
   to the server.  And that will cause DDoS-Like attack to the server
   and bandwidth consumption in the link.

   We test some of the most popular terminals' OS in WLAN, the results
   are illuminated as below.


   --------------------------------------------------------------------
                       DHCP Discovery Packages Time Table
   --------------------------------------------------------------------
     | Windows7   |Windows XP   |  IOS_5.0.1 |Android_2.3.7|Symbian_S60
   No|Time | Time | Time | Time |Time | Time |Time | Time  |Time| Time
     |     |offset|      |offset|     |offset|     |offset |    |offset
   --|-----|------|------|------|-----|------|-----|-------|----|------
   1 |0    |      |0     |      |0.1  |      |7.8  |       |0   |
   2 |3.9  |3.9   |0.1   | 0.1  |1.4  |  1.3 |10.3 |  2.5  |2   |  2
   3 |13.3 |9.4   |4.1   | 4    |3.8  |  2.4 |17.9 |  7.6  |6   |  4
   4 |30.5 |17.2  |12.1  | 8    |7.9  |  4.1 |33.9 |  16   |8   |  2
   5 |62.8 |32.3  |29.1  | 17   |16.3 |  8.4 |36.5 |  2.6  |12  |  4
   6 |65.9 |3.1   |64.9  | 35.8 |24.9 |  8.6 |  reconnect  |14  |  2
   7 |74.9 |9     |68.9  | 4    |33.4 |  8.5 |56.6 |  20.1 |18  |  4
   8 |92.1 |17.2  |77.9  | 9    |42.2 |  8.8 |60.2 |  3.6  |20  |  2
   9 |395.2|303.1 |93.9  | 16   |50.8 |  8.6 |68.4 |  8.2  |24  |  4
   10|399.1|3.9   |433.9 | 340  |59.1 |  8.3 |84.8 |  16.4 |26  |  2
   11|407.1|8     |438.9 | 5    |127.3|  68.2|86.7 |  1.9  |30.1|  4.1
   12|423.4|16.3  |447.9 | 9    |128.9|  1.6 |  reconnect  |32.1|  2
   13|455.4|32    |464.9 | 17   |131.1|  2.2 |106.7|  20   |36.1|  4
   14|460.4|5     |794.9 | 330  |135.1|  4   |111.4|  4.7  |38.1|  2
   15|467.4|7     |799.9 | 5    |143.4|  8.3 |120.6|  9.2  |42.1|  4
   16|483.4|16    |808.9 | 9    |151.7|  8.3 |134.9|  14.3 |44.1|  2
   17|842.9|359.5 |824.9 | 16   |160.4|  8.7 |136.8|  1.9  |48.2|  4.1
   18|846.9|4     |1141.9| 317  |168.8|  8.4 |  reconnect  |50.2|  2
   --------------------------------------------------------------------


   Figure:Terminals DHCPDISCOVER requests when Server's DHCPv4 module is
                                   down

   In this figure:

   For Windows7, it seems to initiate 8 times DHCPDISCOVER requests in
   about 300s interval.

   For WindowsXP, firstly it launches 9 times DHCPDISCOVER messages, but
   after that it cannot get any response from the server, then it




Perreault, et al.         Expires June 7, 2015                 [Page 12]


Internet-Draft                   No IPv4                   December 2014


   initiates 5 times requests in one cycle in around 330s intervals, and
   never stop.

   For IOS5.0.1, it seems like WindowsXP.  There are 10 times attempts
   in one cycle, and the interval is about 68s.

   Symbian_S60 uses the simplest backoff method, it launches DISCOVER in
   every 2 or 4 seconds.

   Android2.3.7 is the only Operating System which can stop DISCOVER
   request by disconnect its wireless connection.  It reboot wireless
   and dhcp connection every 20 seconds.

Authors' Addresses

   Simon Perreault
   Jive Communications
   Quebec, QC
   Canada

   Email: sperreault@jive.com


   Wes George
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171
   USA

   Email: wesley.george@twcable.com


   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1 408 330 4424
   Email: tina.tsou.zouting@huawei.com











Perreault, et al.         Expires June 7, 2015                 [Page 13]


Internet-Draft                   No IPv4                   December 2014


   Tianle Yang
   China Mobile
   32, Xuanwumenxi Ave.
   Xicheng District, Beijing  100053
   China

   Email: yangtianle@chinamobile.com


   Li Lianyuan
   China Mobile
   32,  Xuanwumenxi Ave.
   Xicheng District, Beijing  100053
   China

   Email: lilianyuan@chinamobile.com


   Jean-Francois Tremblay
   Viagenie
   246 Aberdeen
   Quebec, QC  G1R 2E1
   Canada

   Phone: +1 418 656 9254
   Email: jean-francois.tremblay@viagenie.ca
   URI:   http://viagenie.ca
























Perreault, et al.         Expires June 7, 2015                 [Page 14]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/