Network Working Group S. Perreault
Internet-Draft Viagenie
Intended status: Standards Track W. George
Expires: September 09, 2013 Time Warner Cable
T. Tsou
Huawei Technologies (USA)
T. Yang
L. Li
China Mobile
March 08, 2013
Turning off IPv4 Using DHCPv6
draft-perreault-sunset4-noipv4-02
Abstract
This memo defines a new DHCPv6 option for indicating to a dual-stack
host or router that IPv4 is to 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 September 09, 2013.
Copyright Notice
Copyright (c) 2013 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
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
Perreault, et al. Expires September 09, 2013 [Page 1]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
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. The Problems We're Trying to Fix . . . . . . . . . . . . . . 3
3.1. Load on DHCPv4 Server . . . . . . . . . . . . . . . . . . 3
3.2. Bandwidth Consumption . . . . . . . . . . . . . . . . . . 3
3.3. Power Inefficiency . . . . . . . . . . . . . . . . . . . 4
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 4
4.1. DHCPv6 vs DHCPv4 . . . . . . . . . . . . . . . . . . . . 4
5. The No-IPv4 Option . . . . . . . . . . . . . . . . . . . . . 5
5.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Test Results of Terminals Behavior . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
When a dual-stack host makes a DHCPv4 request, it typically
interprets the absence of a response as a failure condition. This
makes it difficult to deploy such nodes in an IPv6-only network.
Take for example a home router that is dual-stack capable but
provisioned with an IPv6-only WAN connection. When the router boots,
it typically assigns an IPv4 address to its LAN interface, starts
services on that interface, and starts handing 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, in turn,
install a default route pointing to the router and start behaving 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 when it is desired that it be turned off.
The other exmaple is about DHCPv4 server. In Dual-Stack LAN/WLAN
network or intranet, the core router or AC often plays the role of
Perreault, et al. Expires September 09, 2013 [Page 2]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
DHCP server, and the clients are serval thousands PC or mobile
phones. If the server is configured in IPv6-only, the dual-stack or
IPv4-only clients will broadcast DHCPDISCOVER messages endlessly in
the LAN or WLAN. The thousands clients will cause a DDOS-like attack
to all the servers in the network. Scince there are not specific
discriptions in any RFCs for client's behavior when it does not
receive the DHCPOFFER in response to its DHCPDISCOVER message,
verious OS deploy different backoff algorithms. We tested serval
popuplar OS(es), the test results is listed in the appendix.
A new mechanism is needed to indicate the absence of IPv4
connectivity or service that the goal is turning off IPv4, this new
signaling mechanism shall be transported over IPv6. Therefore, we
introduce a new DHCPv6 [RFC3315] option for the purpose of explicitly
indicating to the DHCPv6 client 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 DHCPv6 option
is received by a DHCPv6 client.
3. The Problems We're Trying to Fix
3.1. Load on DHCPv4 Server
When a DHCPv4 server is present but intentionally does not respond to
a dual-stack node, the aggregated traffic generated by multiple such
dual-stack nodes can represent a significant useless load. This
scenario can be encountered for example with an ISP serving multiple
types of subscribers where some will get IPv4 addresses and others
not. It might not be feasible for operational reasons to block the
useless requests before they reach the DHCPv4 server, e.g. if the
DHCPv4 server itself is the one that has knowledge about which node
should or should not get an IPv4 address.
3.2. Bandwidth Consumption
In addition to useless load on the DHCPv4 server, the above scenario
could also consume a significant amount of bandwidth, particularly if
the aggregated traffic from many clients goes through a low-bandwidth
link.
Perreault, et al. Expires September 09, 2013 [Page 3]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
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.
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 for turning off IPv4. An
equivalent option could conceivably be created for DHCPv4. Here is a
discussion of the pros and cons. 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
Perreault, et al. Expires September 09, 2013 [Page 4]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
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 it is not as clear for a DHCPv4 option. More feedback on
this topic would be appreciated.
5. The No-IPv4 Option
5.1. Wire Format
The No-IPv4 DHCPv6 option is used to signal the unavailability of
IPv4 connectivity. The format of the 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. Semantics
Perreault, et al. Expires September 09, 2013 [Page 5]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
The option applies to the link on which it is received by the DHCPv6
client. 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.
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.
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-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]
Perreault, et al. Expires September 09, 2013 [Page 6]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
* 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 running the DHCPv6 client that receives this
option MUST disable IPv4 functionality on the Upstream Interface
in the same way as for value 1 or 2.
If all DHCPv6-configured interfaces received the No-IPv4 option
with exclusively 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.
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.
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.
Perreault, et al. Expires September 09, 2013 [Page 7]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
5.3. 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.
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.
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
Perreault, et al. Expires September 09, 2013 [Page 8]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
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].
8. Acknowledgements
Thanks in particular to Marc Blanchet who was the driving force
behind this work.
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.
9.2. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
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.
Perreault, et al. Expires September 09, 2013 [Page 9]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
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 |
------------------------------------------------------------------------
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.
Perreault, et al. Expires September 09, 2013 [Page 10]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
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.
Authors' Addresses
Simon Perreault
Viagenie
246 Aberdeen
Quebec, QC G1R 2E1
Canada
Phone: +1 418 656 9254
Email: simon.perreault@viagenie.ca
URI: http://viagenie.ca
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 September 09, 2013 [Page 11]
Internet-Draft Turning off IPv4 Using DHCPv6 March 2013
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
Perreault, et al. Expires September 09, 2013 [Page 12]