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