Jive Communications

Québec QC Canada sperreault@jive.com

Time Warner Cable

13820 Sunrise Valley Drive Herndon VA 20171 USA wesley.george@twcable.com

Huawei Technologies (USA)

2330 Central Expressway Santa Clara CA 95050 USA +1 408 330 4424 tina.tsou.zouting@huawei.com

China Mobile

32, Xuanwumenxi Ave. Xicheng District Beijing 100053 China yangtianle@chinamobile.com

China Mobile

32, Xuanwumenxi Ave. Xicheng District Beijing 100053 China lilianyuan@chinamobile.com

Viagénie

246 Aberdeen Québec QC G1R 2E1 Canada +1 418 656 9254 jean-francois.tremblay@viagenie.ca http://viagenie.ca

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.

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 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 . 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 . Although DHCP mandates a exponential backoff, it is limited to 64 seconds, which may still generate significant traffic (see section 4.1 of ). 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 option and a new Router Advertisement (RA) option for the purpose of explicitly indicating to the host that IPv4 connectivity is unavailable.

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 . The following terms are also used in this document: An interface on which the No-IPv4 option is received over either DHCPv6 or RA.

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.

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.

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.

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.

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. 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.

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.

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

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 ( 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.

The format of the RA 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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.

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: 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. 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: IPv4 addresses MUST NOT be assigned. Currently-assigned IPv4 addresses MUST be unassigned. Dynamic configuration of link-local IPv4 addresses MUST be disabled. IPv4, ICMPv4, or ARP packets MUST NOT be sent. IPv4, ICMPv4, or ARP packets received MUST be ignored. DNS A queries MUST NOT be sent, even transported over IPv6. 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) Private-Use (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) 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: IPv4 address MUST NOT be assigned to any interface. Currently-assigned IPv4 addresses MUST be unassigned. Dynamic configuration of link-local IPv4 addresses MUST be disabled. IPv4, ICMPv4, or ARP packets MUST NOT be sent on any interface. IPv4, ICMPv4, or ARP packets received on any interface MUST be ignored. In the above, "any interface" includes loopback interfaces. In particular, the 127.0.0.1 special address MUST be removed. Server programs listening on IPv4 addresses (e.g., a DHCPv4 server) MAY be shut down. DNS A queries MUST NOT be sent, even transported over IPv6. 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. 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.

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. 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.

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 ( section 7). TO BE COMPLETED

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. 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.

Thanks in particular to Marc Blanchet who was the driving force behind this work. Rajiv Asati contributed section .

Cisco systems

170 West Tasman Drive San Jose CA 95134-1706 US +1 914 528 0090 +1 408 526 4952 yakov@cisco.com

Chrysler Corporation

25999 Lawrence Ave Center Line MI 48015 US +1 810 758 8212 +1 810 758 8173 rgm3@is.chrysler.com

RIPE Network Coordination Centre

Kruislaan 409 Amsterdam 1098 SJ NL +31 20 5925065 +31 20 5925090 Daniel.Karrenberg@ripe.net

RIPE Network Coordination Centre

Kruislaan 409 Amsterdam 1098 SJ NL +31 20 5925065 +31 20 5925090 GeertJan.deGroot@ripe.net

Silicon Graphics, Inc.

2011 N. Shoreline Blvd. Mail Stop 15-730 Mountain View CA 94043-1389 US +1 415 960 1980 +1 415 961 9584 lear@sgi.com

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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 RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.</t><t> IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK] This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] Computer Science Department

323 Dana Engineering Bucknell University Lewisburg PA 17837 (717) 524-1145 droms@bucknell.edu

Internet DHCP configuration dynamic host configuration protocol host The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP) , adding the capability of automatic allocation of reusable network addresses and additional configuration options . DHCP captures the behavior of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants . This document updates RFC 3315 by redefining the default values for SOL_MAX_RT and INF_MAX_RT and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT and INF_MAX_RT with new values. When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK]

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 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 --------------------------------------------------------------------

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 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.