draft-ietf-sunset4-noipv4-00.txt   draft-ietf-sunset4-noipv4-01.txt 
Network Working Group S. Perreault Network Working Group S. Perreault
Internet-Draft Viagenie Internet-Draft Jive Communications
Intended status: Standards Track W. George Intended status: Standards Track W. George
Expires: March 28, 2014 Time Warner Cable Expires: June 7, 2015 Time Warner Cable
T. Tsou T. Tsou
Huawei Technologies (USA) Huawei Technologies (USA)
T. Yang T. Yang
L. Li L. Li
China Mobile China Mobile
September 24, 2013 JF. Tremblay
Viagenie
December 4, 2014
Turning off IPv4 Using DHCPv6 or Router Advertisements Turning off IPv4 Using DHCPv6 or Router Advertisements
draft-ietf-sunset4-noipv4-00 draft-ietf-sunset4-noipv4-01
Abstract Abstract
This memo defines a new DHCPv6 option and a new Router Advertisement This memo defines a new DHCPv6 option and a new Router Advertisement
option for indicating to a dual-stack host or router that IPv4 is to option to inform a dual-stack host or router that IPv4 can be turned
be turned off. off.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 28, 2014. This Internet-Draft will expire on June 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Problems We're Trying to Fix . . . . . . . . . . . . . . 4 3. Problems Being Addressed . . . . . . . . . . . . . . . . . . 3
3.1. Load on DHCPv4 Server . . . . . . . . . . . . . . . . . . 4 3.1. Load on DHCPv4 Server and Relay . . . . . . . . . . . . . 4
3.2. Bandwidth Consumption . . . . . . . . . . . . . . . . . . 4 3.2. Bandwidth Consumption . . . . . . . . . . . . . . . . . . 4
3.3. Power Inefficiency . . . . . . . . . . . . . . . . . . . 4 3.3. Power Inefficiency . . . . . . . . . . . . . . . . . . . 4
3.4. IPv4 only Applications . . . . . . . . . . . . . . . . . 4 3.4. IPv4 Only Applications . . . . . . . . . . . . . . . . . 4
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 4 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 4
4.1. DHCPv6 vs DHCPv4 . . . . . . . . . . . . . . . . . . . . 4 4.1. DHCPv6 vs DHCPv4 . . . . . . . . . . . . . . . . . . . . 4
4.2. DHCPv6 vs RA . . . . . . . . . . . . . . . . . . . . . . 5 4.2. DHCPv6 vs RA . . . . . . . . . . . . . . . . . . . . . . 6
5. The No-IPv4 Option . . . . . . . . . . . . . . . . . . . . . 6 5. The No-IPv4 DHCPv6 Option . . . . . . . . . . . . . . . . . . 6
5.1. DHCPv6 Wire Format . . . . . . . . . . . . . . . . . . . 6 5.1. DHCPv6 Wire Format . . . . . . . . . . . . . . . . . . . 6
5.2. RA Wire Format . . . . . . . . . . . . . . . . . . . . . 6 5.2. RA Wire Format . . . . . . . . . . . . . . . . . . . . . 6
5.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Test Results of Terminals Behavior . . . . . . . . . 11 Appendix A. Test Results of Terminals Behavior . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
When a dual-stack host makes a DHCPv4 request, it typically When a dual-stack host makes a DHCPv4 request, it typically
interprets the absence of a response as a failure condition. This interprets the absence of a response as a failure condition. This
makes it difficult to deploy such nodes in an IPv6-only network. 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.
Take for example a home router that is dual-stack capable but One situation where problems arise is with a dual-stack home router
provisioned with an IPv6-only WAN connection. When the router boots, provisioned with an IPv6-only WAN connection. It typically assigns
it typically assigns an IPv4 address to its LAN interface, starts an IPv4 address to its LAN interface, starts services on that
services on that interface, and starts handing out IPv4 addresses to interface and hands out IPv4 addresses to clients on the LAN by
clients on the LAN by answering DHCPv4 requests. This is done answering DHCPv4 requests. This is done unconditionally, without
unconditionally, without taking the status of the IPv4 connectivity taking the status of the IPv4 connectivity on the WAN interface into
on the WAN interface into account. Hosts on the LAN, in turn, account. Hosts on the LAN install a default route pointing to the
install a default route pointing to the router and start behaving as router and behave as if IPv4 connectivity was available. IPv4
if IPv4 connectivity was available. IPv4 packets destined to the packets destined to the Internet get dropped at the router and
Internet get dropped at the router and timeouts happen. The end timeouts happen. The end result is that IPv4 remains fully active on
result is that IPv4 remains fully active on the LAN and on the router the LAN and on the router itself even if it would be desirable to
itself even when it is desired that it be turned off. turn it off, especially for applications that do not implement Happy
Eyeballs [RFC6555].
The other exmaple is about DHCPv4 server. In Dual-Stack LAN/WLAN Another situation relates to the load on DHCPv4 servers and relays.
network or intranet, the core router or AC often plays the role of In large dual-stack network (LAN, WLAN), thousands of hosts,
DHCP server, and the clients are server thousands PC or mobile including mobile phones, may generate a significant amount of trafic
phones. If the server is configured in IPv6-only, the dual-stack or by attempting to contact a DHCP server. If the servers and relays
IPv4-only clients will broadcast DHCPDISCOVER messages endlessly in are configured in IPv6-only, the dual-stack or IPv4-only clients will
the LAN or WLAN. The thousands clients will cause a DDOS-like attack broadcast DHCPDISCOVER messages endlessly, creating a DDOS-like
to all the servers in the network. Since there are not specific attack on the network. This scenario has also been briefly described
descriptions in any RFCs for client's behavior when it does not for DHCPv6 in [RFC7083]. Although DHCP mandates a exponential
receive the DHCPOFFER in response to its DHCPDISCOVER message, backoff, it is limited to 64 seconds, which may still generate
various OS deploy different backoff algorithms. We tested server significant traffic (see section 4.1 of [RFC2131]). Various
popuplar OS(es), the test results is listed in the appendix. 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 A new mechanism is needed to indicate the absence of IPv4
connectivity or service that the goal is turning off IPv4, this new connectivity. Considering the end goal is turn off all IPv4
signaling mechanism shall be transported over IPv6. Therefore, we connectivity, the chosen mechanism should be transported over IPv6.
introduce a new DHCPv6 [RFC3315] option and a new Router Therefore, this document introduce a new DHCPv6 [RFC3315] option and
Advertisement (RA) [RFC4861] option for the purpose of explicitly a new Router Advertisement (RA) [RFC4861] option for the purpose of
indicating to the host that IPv4 connectivity is unavailable. explicitly indicating to the host that IPv4 connectivity is
unavailable.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The following terms are also used in this document: The following terms are also used in this document:
Upstream Interface: An interface on which the No-IPv4 option is Upstream Interface: An interface on which the No-IPv4 option is
received over either DHCPv6 or RA. received over either DHCPv6 or RA.
3. The Problems We're Trying to Fix 3. Problems Being Addressed
3.1. Load on DHCPv4 Server and Relay
3.1. Load on DHCPv4 Server
When a DHCPv4 server is present but intentionally does not respond to When a DHCPv4 server or relay is present but intentionally does not
a dual-stack node, the aggregated traffic generated by multiple such react to DHCPDISCOVERs, the aggregated traffic generated by a large
dual-stack nodes can represent a significant useless load. This number of dual-stack hosts can represent a significant bandwidth
scenario can be encountered for example with an ISP serving multiple load. This scenario is encountered with an ISP serving multiple
types of subscribers where some will get IPv4 addresses and others types of subscribers where some a provisioned for IP4 service and
not. It might not be feasible for operational reasons to block the others are not. It might not be feasible for operational reasons to
useless requests before they reach the DHCPv4 server, e.g. if the block the useless requests before they reach the DHCPv4 servers, for
DHCPv4 server itself is the one that has knowledge about which node example if the DHCPv4 servers themselves are the only ones with the
should or should not get an IPv4 address. knowledge of which nodes should or should not get an IPv4 address.
3.2. Bandwidth Consumption 3.2. Bandwidth Consumption
In addition to useless load on the DHCPv4 server, the above scenario In addition to the useless load on the DHCPv4 servers, the above
could also consume a significant amount of bandwidth, particularly if scenario could also consume a significant amount of bandwidth,
the aggregated traffic from many clients goes through a low-bandwidth especially if the aggregated traffic from many clients goes through a
link. low-bandwidth link or through a wireless link.
3.3. Power Inefficiency 3.3. Power Inefficiency
A dual-stack node that does not get a DHCPv4 response will usually A dual-stack node that does not get a DHCPv4 response will usually
continue retransmitting forever. Therefore, only providing IPv6 on a continue retransmitting forever. Therefore, only providing IPv6 on a
link will cause the node to needlessly wake up periodically and link will cause the node to needlessly wake up periodically and
transmit a few packets. For example, the popular DHCPv4 client transmit a few packets. For example, the popular DHCPv4 client
implementation by ISC wakes up every 5 minutes by default and tries implementation by ISC wakes up every 5 minutes by default and tries
to contact a DHCPv4 server for 60 seconds. With this configuration, to contact a DHCPv4 server for 60 seconds. With this configuration,
a node will not be able to sleep 20% of the time. a node will not be able to sleep 20% of the time.
3.4. IPv4 only Applications 3.4. IPv4 Only Applications
In many cases, IPv4-only applications such as Skype use IPv4 LLA to In many cases, IPv4-only applications such as Skype use an
bombard the LAN with IPv4 packets. In an IPv6-only environment, it autoconfigured IPv4 Link-Local Addresses (LLA) to send IPv4 packets
can get quite annoying and waste a lot of bandwidth. on the LAN. In an IPv6-only environment, this behavior may waste a
significant amount of bandwidth.
4. Design Considerations 4. Design Considerations
4.1. DHCPv6 vs DHCPv4 4.1. DHCPv6 vs DHCPv4
NOTE: This section will be removed before publication as an RFC. NOTE: This section will be removed before publication as an RFC.
This document describes a new DHCPv6 option for turning off IPv4. An This document describes a new DHCPv6 option to turn off IPv4. An
equivalent option could conceivably be created for DHCPv4. Here is a equivalent option could conceivably be created for DHCPv4. The pros
discussion of the pros and cons. Arguments with a + sign argue for a and cons are discussed below. Arguments with a + sign argue for a
DHCPv4 option, arguments with a - sign argue against. DHCPv4 option, arguments with a - sign argue against.
+ Devices that don't speak IPv6 won't be listening for a "turn off + 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 IPv4" code, and therefore won't stop trying to establish IPv4
connectivity. connectivity.
- Devices that haven't been updated to speak IPv6 likely won't - Devices that haven't been updated to speak IPv6 likely won't
recognize a new DHCPv4 code telling them that IPv4 isn't recognize a new DHCPv4 code telling them that IPv4 isn't
supported. supported.
+ However, it's easier to implement something that + However, it's easier to implement something that turns off
turns off the IP stack than implement IPv6. the IP stack than implement IPv6.
- Devices that don't speak IPv6 that are still active on the network - 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 mean that either IPv4 can't/shouldn't be turned off yet, or IPv4
local connectivity should be maintained to retain local services, local connectivity should be maintained to retain local services,
even if global IPv4 connectivity is not necessary (think local LAN even if global IPv4 connectivity is not necessary (think local LAN
DLNA streaming, etc). DLNA streaming, etc).
- When the goal is to turn off IPv4, having to maintain and operate - When the goal is to turn off IPv4, having to maintain and operate
an IPv4 infrastructure (routing, ACLs, etc.) just to be able to an IPv4 infrastructure (routing, ACLs, etc.) just to be able to
send negative responses to DHCPv4 requests is not productive. send negative responses to DHCPv4 requests is not productive.
Having the option transported in IPv6 allows the ISP to focus on Having the option transported in IPv6 allows the ISP to focus on
operating an IPv6-only network. operating an IPv6-only network.
+ However, a full IPv4 infrastructure would not be necessary + However, a full IPv4 infrastructure would not be necessary in
in many cases. The local router could contain a very many cases. The local router could contain a very restricted
restricted DHCPv4 server function whose only purpose would DHCPv4 server function whose only purpose would be to reply
be to reply with the No-IPv4 option. No IPv4 traffic would with the No-IPv4 option. No IPv4 traffic would have to be
have to be carried to a distant DHCPv4 server. Note however carried to a distant DHCPv4 server. Note however that this may
that this may not be operationally feasible in some not be operationally feasible in some situations.
situations.
- Turning IPv4 off using an IPv4-transported signal means that there - 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 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 the DHCPv4 client, IPv4 can no longer be turned on remotely
(rebooting the client still works). Configurations change, (rebooting the client still works). Configurations change,
mistakes happen, and so it is necessary to have a way to turn IPv4 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 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 as the client makes a new DHCPv6 request, which can be the next
scheduled one or can be triggered immediately with a Reconfigure scheduled one or can be triggered immediately with a Reconfigure
message. message.
The authors conclude that a DHCPv6 option is clearly necessary, The authors conclude that a DHCPv6 option is clearly necessary,
whereas it is not as clear for a DHCPv4 option. More feedback on whereas the need for a DHCPv4 option is not as obvious. More
this topic would be appreciated. feedback on this topic would be appreciated.
4.2. DHCPv6 vs RA 4.2. DHCPv6 vs RA
Both DHCPv6- and RA-based solutions are presented in this draft. It
Both DHCPv6 and RA-based solutions are presented in this draft. It
is expected that the working group will decide whether both is expected that the working group will decide whether both
solutions, only one, or none are desirable. solutions, only one, or none are desirable.
5. The No-IPv4 Option 5. The No-IPv4 DHCPv6 Option
The No-IPv4 DHCPv6 option is used to signal the unavailability of The No-IPv4 DHCPv6 option is used to signal the unavailability of
IPv4 connectivity. IPv4 connectivity.
5.1. DHCPv6 Wire Format 5.1. DHCPv6 Wire Format
The format of the DHCPv6 No-IPv4 option is: The format of the DHCPv6 No-IPv4 option is:
0 1 2 3 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 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
skipping to change at page 7, line 36 skipping to change at page 7, line 47
1 - No IPv4 upstream: Any kind of IPv4 connectivity is unavailable 1 - No IPv4 upstream: Any kind of IPv4 connectivity is unavailable
on the link on which the option is received. Therefore, any on the link on which the option is received. Therefore, any
attempts to provision IPv4 by the host or to use IPv4 in 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, fashion, on that link, will be useless. IPv4 MAY be dropped,
blocked, or otherwise ignored on that link. blocked, or otherwise ignored on that link.
Upon reception of the No-IPv4 option with value 1, the following Upon reception of the No-IPv4 option with value 1, the following
IPv4 functionality MUST be disabled on the Upstream Interface: IPv4 functionality MUST be disabled on the Upstream Interface:
a. IPv4 addresses MUST NOT be assigned. A. IPv4 addresses MUST NOT be assigned.
b. Currently-assigned IPv4 addresses MUST be unassigned. B. Currently-assigned IPv4 addresses MUST be unassigned.
c. Dynamic configuration of link-local IPv4 addresses [RFC3927] C. Dynamic configuration of link-local IPv4 addresses [RFC3927]
MUST be disabled. MUST be disabled.
d. IPv4, ICMPv4, or ARP packets MUST NOT be sent. D. IPv4, ICMPv4, or ARP packets MUST NOT be sent.
e. IPv4, ICMPv4, or ARP packets received MUST be ignored. E. IPv4, ICMPv4, or ARP packets received MUST be ignored.
f. DNS A queries MUST NOT be sent, even transported over IPv6. F. DNS A queries MUST NOT be sent, even transported over IPv6.
2 - No IPv4 upstream, local IPv4 restricted: Same semantics as value 2 - No IPv4 upstream, local IPv4 restricted: Same semantics as value
1, with the following additions: 1, with the following additions:
If all DHCPv6- or RA-configured interfaces receive the No-IPv4 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), option with a mix of values 1, 2, and 3 (but not exclusively 3),
and no other interface provides IPv4 connectivity to the Internet, and no other interface provides IPv4 connectivity to the Internet,
IPv4 is partially shut down, leaving only local connectivity IPv4 is partially shut down, leaving only local connectivity
active. On the Upstream Interface, IPv4 MUST be shut down as active. On the Upstream Interface, IPv4 MUST be shut down as
listed above. On other interfaces, IPv4 addresses MUST NOT be listed above. On other interfaces, IPv4 addresses MUST NOT be
skipping to change at page 8, line 27 skipping to change at page 8, line 36
* Private-Use (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) * Private-Use (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
[RFC1918] [RFC1918]
3 - No IPv4 at all: This is intended to be a stricter version of the 3 - No IPv4 at all: This is intended to be a stricter version of the
above. above.
The host or router receiving this option MUST disable IPv4 The host or router receiving this option MUST disable IPv4
functionality on the Upstream Interface in the same way as for functionality on the Upstream Interface in the same way as for
value 1 or 2. value 1 or 2.
If all DHCPv6- or RA-configured interfaces received the No-IPv4 If all DHCPv6 or RA-configured interfaces received the No-IPv4
option with exclusively value 3, and no other interface provides option with value 3, and no other interface provides IPv4
IPv4 connectivity to the Internet, IPv4 is completely shut down. connectivity to the Internet, IPv4 is completely shut down. In
In particular: particular:
a. IPv4 address MUST NOT be assigned to any interface. A. IPv4 address MUST NOT be assigned to any interface.
b. Currently-assigned IPv4 addresses MUST be unassigned. B. Currently-assigned IPv4 addresses MUST be unassigned.
c. Dynamic configuration of link-local IPv4 addresses [RFC3927] C. Dynamic configuration of link-local IPv4 addresses [RFC3927]
MUST be disabled. MUST be disabled.
d. IPv4, ICMPv4, or ARP packets MUST NOT be sent on any D. IPv4, ICMPv4, or ARP packets MUST NOT be sent on any
interface. interface.
e. IPv4, ICMPv4, or ARP packets received on any interface MUST be E. IPv4, ICMPv4, or ARP packets received on any interface MUST be
ignored. ignored.
f. In the above, "any interface" includes loopback interfaces. F. In the above, "any interface" includes loopback interfaces.
In particular, the 127.0.0.1 special address MUST be removed. In particular, the 127.0.0.1 special address MUST be removed.
g. Server programs listening on IPv4 addresses (e.g., a DHCPv4 G. Server programs listening on IPv4 addresses (e.g., a DHCPv4
server) MAY be shut down. server) MAY be shut down.
h. DNS A queries MUST NOT be sent, even transported over IPv6. 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 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 include the No-IPv4 option with value 2 in DHCPv6 responses it
sends to clients that request it, unless prohibited by local sends to clients that request it, unless prohibited by local
policy. If it currently has active clients, it SHOULD send a policy. If it currently has active clients, it SHOULD send a
Reconfigure to each of them with the OPTION_NO_IPV4 included Reconfigure to each of them with the OPTION_NO_IPV4 included
in the Option Request Option. in the Option Request Option.
j. If the router sends Router Advertisement, it SHOULD include J. If the router sends Router Advertisement, it SHOULD include
the No-IPv4 option with value 2 in RA messages it sends, the No-IPv4 option with value 2 in RA messages it sends,
unless prohibited by local policy. It SHOULD also send RAs unless prohibited by local policy. It SHOULD also send RAs
immediately so that the changes take effect for all current immediately so that the changes take effect for all current
hosts. hosts.
The intent is to remove all traces of IPv4 activity. Once the No- The intent is to remove all traces of IPv4 activity. Once the No-
IPv4 option with value 3 is activated, the network stack should IPv4 option with value 3 is activated, the network stack should
behave as if IPv4 functionality had never been present. For behave as if IPv4 functionality had never been present. For
example, a modular kernel implementation could accomplish the example, a modular kernel implementation could accomplish the
above by unloading the IPv4 kernel module at run time. above by unloading the IPv4 kernel module at run time.
skipping to change at page 10, line 8 skipping to change at page 10, line 16
request containing OPTION_NO_IPV4 in an Option Request Option. The 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. ISP's DHCPv6 server's reply includes the No-IPv4 option with value 3.
When this procedure finishes, the ISP has determined that this When this procedure finishes, the ISP has determined that this
customer will run in IPv6-only mode and starts dropping all IPv4 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 packets at the first hop. If an IPv4 address was assigned, it is
reclaimed, and possibly reassigned to another subscriber. reclaimed, and possibly reassigned to another subscriber.
The home router aborts the IPv4 provisioning procedure (if it is The home router aborts the IPv4 provisioning procedure (if it is
still running) and deactivates all IPv4 functionality. It shuts down still running) and deactivates all IPv4 functionality. It shuts down
its DHCPv4 server. It also configures its own stateless DHCPv6 its DHCPv4 server. It also configures its own stateless DHCPv6
server to send the No-IPv4 option to clients that request it. 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 As an optimization, the router could delay setting up IPv4 by a few
seconds (10 seconds seems reasonable). If the IPv6 procedure seconds (10 seconds seems reasonable). If the IPv6 procedure
completes with the No-IPv4 option during that time, IPv4 will never 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 have been set up and the router will operate in pure IPv6-only mode
from the start. from the start.
6. Security Considerations 6. Security Considerations
One security concern is that an attacker could use the No-IPv4 option One security concern is that an attacker could use the No-IPv4 option
skipping to change at page 11, line 22 skipping to change at page 11, line 33
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
9.2. Informative References 9.2. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 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 Appendix A. Test Results of Terminals Behavior
In RFC3315 [RFC3315, DHCPv6], SOL_MAX_RT is defined in DHCPv6 to In RFC3315 [RFC3315, DHCPv6], SOL_MAX_RT is defined in DHCPv6 to
prevent the frequently requesting of clients, which reduces the prevent the frequently requesting of clients, which reduces the
aggregated traffic. But in RFC2131 [RFC2131, DHCPv4], there are not aggregated traffic. But in RFC2131 [RFC2131, DHCPv4], there are not
corresponding IPv4 definitions or options for client's behavior if corresponding IPv4 definitions or options for client's behavior if
the server does not respond for the Discover messages. the server does not respond for the Discover messages.
In fact, most of the terminals creat backoff algorithms to help them In fact, most of the terminals creat backoff algorithms to help them
retransmit DHCPDISCOVER message in different frequency according to retransmit DHCPDISCOVER message in different frequency according to
skipping to change at page 13, line 4 skipping to change at page 13, line 18
in one cycle, and the interval is about 68s. in one cycle, and the interval is about 68s.
Symbian_S60 uses the simplest backoff method, it launches DISCOVER in Symbian_S60 uses the simplest backoff method, it launches DISCOVER in
every 2 or 4 seconds. every 2 or 4 seconds.
Android2.3.7 is the only Operating System which can stop DISCOVER Android2.3.7 is the only Operating System which can stop DISCOVER
request by disconnect its wireless connection. It reboot wireless request by disconnect its wireless connection. It reboot wireless
and dhcp connection every 20 seconds. and dhcp connection every 20 seconds.
Authors' Addresses Authors' Addresses
Simon Perreault Simon Perreault
Viagenie Jive Communications
246 Aberdeen Quebec, QC
Quebec, QC G1R 2E1
Canada Canada
Phone: +1 418 656 9254 Email: sperreault@jive.com
Email: simon.perreault@viagenie.ca
URI: http://viagenie.ca
Wes George Wes George
Time Warner Cable Time Warner Cable
13820 Sunrise Valley Drive 13820 Sunrise Valley Drive
Herndon, VA 20171 Herndon, VA 20171
USA USA
Email: wesley.george@twcable.com Email: wesley.george@twcable.com
Tina Tsou Tina Tsou
skipping to change at line 588 skipping to change at page 14, line 19
Email: yangtianle@chinamobile.com Email: yangtianle@chinamobile.com
Li Lianyuan Li Lianyuan
China Mobile China Mobile
32, Xuanwumenxi Ave. 32, Xuanwumenxi Ave.
Xicheng District, Beijing 100053 Xicheng District, Beijing 100053
China China
Email: lilianyuan@chinamobile.com 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
 End of changes. 52 change blocks. 
111 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/