draft-ietf-v6ops-v6onbydefault-01.txt | draft-ietf-v6ops-v6onbydefault-02.txt | |||
---|---|---|---|---|
Network Working Group S. Roy | Network Working Group S. Roy | |||
Internet-Draft A. Durand | Internet-Draft A. Durand | |||
Expires: August 13, 2004 J. Paugh | Expires: November 5, 2004 J. Paugh | |||
Sun Microsystems, Inc. | Sun Microsystems, Inc. | |||
February 13, 2004 | May 7, 2004 | |||
Issues with Dual Stack IPv6 on by Default | Issues with Dual Stack IPv6 on by Default | |||
draft-ietf-v6ops-v6onbydefault-01.txt | draft-ietf-v6ops-v6onbydefault-02.txt | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that other | |||
groups may also distribute working documents as Internet-Drafts. | groups may also distribute working documents as Internet-Drafts. | |||
skipping to change at page 1, line 32 | skipping to change at page 1, line 31 | |||
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." | |||
The list of current Internet-Drafts can be accessed at http:// | The list of current Internet-Drafts can be accessed at http:// | |||
www.ietf.org/ietf/1id-abstracts.txt. | www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on August 13, 2004. | This Internet-Draft will expire on November 5, 2004. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2004). All Rights Reserved. | |||
Abstract | Abstract | |||
This document discusses problems that can occur when dual stack nodes | This document discusses problems that can occur when dual stack nodes | |||
that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 | that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 | |||
and IPv6 environments. The problems include application connection | and IPv6 environments. The problems include application connection | |||
delays, poor connectivity, and network security. Its purpose is to | delays, poor connectivity, and network insecurity. The purpose of | |||
raise awareness of these problems so that they can be fixed or worked | this memo is to raise awareness of these problems so that they can be | |||
around. The purpose of this document is not to try to specify whether | fixed or worked around, not to try to specify whether IPv6 should be | |||
IPv6 should be enabled by default or not, but to raise awareness of | enabled by default or not. | |||
the potential issues involved. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. No IPv6 Router . . . . . . . . . . . . . . . . . . . . . . 3 | 2. No IPv6 Router . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1 Problems with Default Address Selection for IPv6 . . . . . 3 | 2.1 Problems with Default Address Selection for IPv6 . . . . . 3 | |||
2.2 Neighbor Discovery's On-Link Assumption Considered | 2.2 Neighbor Discovery's On-Link Assumption Considered | |||
Harmful . . . . . . . . . . . . . . . . . . . . . . . . . 5 | Harmful . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.3 Transport Protocol Robustness . . . . . . . . . . . . . . 6 | 2.3 Transport Protocol Robustness . . . . . . . . . . . . . . 6 | |||
2.3.1 TCP Implications . . . . . . . . . . . . . . . . . . . . . 6 | 2.3.1 TCP Implications . . . . . . . . . . . . . . . . . . . 6 | |||
2.3.1.1 TCP Connection Termination . . . . . . . . . . . . . . . . 6 | 2.3.2 UDP Implications . . . . . . . . . . . . . . . . . . . 8 | |||
2.3.1.2 Asynchronous Application Notification . . . . . . . . . . 7 | 2.3.3 SCTP Implications . . . . . . . . . . . . . . . . . . 8 | |||
2.3.2 UDP Implications . . . . . . . . . . . . . . . . . . . . . 7 | 3. Other Problematic Scenarios . . . . . . . . . . . . . . . . . 9 | |||
2.3.3 SCTP Implications . . . . . . . . . . . . . . . . . . . . 8 | 3.1 IPv6 Network of Smaller Scope . . . . . . . . . . . . . . 9 | |||
3. Other Problematic Scenarios . . . . . . . . . . . . . . . 8 | 3.1.1 Alleviating the Scope Problem . . . . . . . . . . . . 10 | |||
3.1 IPv6 Network of Smaller Scope . . . . . . . . . . . . . . 8 | 3.2 Poor IPv6 Network Performance . . . . . . . . . . . . . . 10 | |||
3.1.1 Alleviating the Scope Problem . . . . . . . . . . . . . . 8 | 3.2.1 Dealing with Poor IPv6 Network Performance . . . . . . 10 | |||
3.2 Poor IPv6 Network Performance . . . . . . . . . . . . . . 8 | 3.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.2.1 Dealing with Poor IPv6 Network Performance . . . . . . . . 9 | 3.3.1 Mitigating Security Risks . . . . . . . . . . . . . . 11 | |||
3.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4. Application Robustness . . . . . . . . . . . . . . . . . . . . 12 | |||
3.3.1 Mitigating Security Risks . . . . . . . . . . . . . . . . 10 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
4. Application Robustness . . . . . . . . . . . . . . . . . . 10 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . 11 | 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 | |||
Normative References . . . . . . . . . . . . . . . . . . . 11 | 6.2 Informative References . . . . . . . . . . . . . . . . . . . 13 | |||
Informative References . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 | A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 12 | B. Changes from draft-ietf-v6ops-v6onbydefault-01 . . . . . . . . 14 | |||
B. Changes from draft-ietf-v6ops-v6onbydefault-00 . . . . . . 12 | C. Changes from draft-ietf-v6ops-v6onbydefault-00 . . . . . . . . 14 | |||
Intellectual Property and Copyright Statements . . . . . . 14 | Intellectual Property and Copyright Statements . . . . . . . . 16 | |||
1. Introduction | 1. Introduction | |||
This document specifically addresses operating system implementations | This document specifically addresses operating system implementations | |||
that implement the dual stack IPv6 model, and would ship with IPv6 | that implement the dual stack IPv6 model, and would ship with IPv6 | |||
enabled by default. It addresses the case where such a system is | enabled by default. It addresses the case where such systems are | |||
installed and placed in an IPv4 only or mixed IPv4 and IPv6 | installed and placed in IPv4-only or mixed IPv4 and IPv6 | |||
environment, and documents potential problems that users on such | environments, and documents potential problems that users on such | |||
systems could experience if the IPv6 connectivity is non-existent or | systems could experience if the IPv6 connectivity is non-existent or | |||
sub-optimal. The purpose of this document is not to try to specify | sub-optimal. The purpose of this document is not to try to specify | |||
whether IPv6 should be enabled by default or not, but to raise | whether IPv6 should be enabled by default or not, but to raise | |||
awareness of the potential issues involved. | awareness of the potential issues involved. | |||
It begins in Section 2 by examining problems within IPv6 | This memo begins in Section 2 by examining problems within IPv6 | |||
implementations that defeat the destination address selection | implementations that defeat the destination address selection | |||
mechanism defined in [ADDRSEL] and contribute to poor IPv6 | mechanism defined in [ADDRSEL] and contribute to poor IPv6 | |||
connectivity. Starting with Section 3 it then examines other issues | connectivity. Starting with Section 3 it then examines other issues | |||
that network software engineers and network and systems | that network software engineers and network and systems | |||
administrators should be aware of when deploying dual stack systems | administrators should be aware of when deploying dual stack systems | |||
with IPv6 enabled. | with IPv6 enabled. | |||
2. No IPv6 Router | 2. No IPv6 Router | |||
Consider a scenario in which a dual stack system has IPv6 enabled and | Consider a scenario in which a dual stack system has IPv6 enabled and | |||
placed on a link with no IPv6 routers. The system is using IPv6 | is placed on a link with no IPv6 routers. The system is using IPv6 | |||
Stateless Address Autoconfiguration [AUTOCONF], so it only has a | Stateless Address Autoconfiguration [AUTOCONF], so it only has a | |||
link-local IPv6 address configured. It also has a single IPv4 | link-local IPv6 address configured. It also has a single IPv4 | |||
address that happens to be a private address as defined in | address that happens to be a private address as defined in | |||
[PRIVADDR]. | [PRIVADDR]. | |||
An application on this system is trying to communicate with a | An application on this system is trying to communicate with a | |||
destination whose name resolves to public and global IPv4 and IPv6 | destination whose name resolves to public and global IPv4 and IPv6 | |||
addresses. The application uses an address resolution API that | addresses. The application uses an address resolution API that | |||
implements the destination address selection mechanism described in | implements the destination address selection mechanism described in | |||
Default Address Selection for IPv6 [ADDRSEL]. The application will | Default Address Selection for IPv6 [ADDRSEL]. The application will | |||
attempt to connect to each address returned in order until one | attempt to connect to each address, in the order they were returned, | |||
succeeds. Since the system has no off-link IPv6 routes, the optimal | until one succeeds. Since the system has no off-link IPv6 routes, | |||
scenario would be if the IPv4 addresses returned were ordered before | the optimal scenario would be if the IPv4 addresses returned were | |||
the IPv6 addresses. The following sections describe where things can | ordered before the IPv6 addresses. The following sections describe | |||
go wrong with this scenario. | what things can go wrong with this scenario. | |||
2.1 Problems with Default Address Selection for IPv6 | 2.1 Problems with Default Address Selection for IPv6 | |||
The Default Address Selection for IPv6 [ADDRSEL] destination address | The Default Address Selection for IPv6 [ADDRSEL] destination address | |||
selection mechanism could save the application a few useless | selection mechanism could save the application a few useless | |||
connection attempts by placing the IPv4 addresses in front of the | connection attempts by placing the IPv4 addresses in front of the | |||
IPv6 addresses. This would be desired since all IPv6 destinations in | IPv6 addresses. This would be desired since all IPv6 destinations in | |||
this scenario are unreachable (there's no route to them), and the | this scenario are unreachable (there's no route to them), and the | |||
system's only IPv6 source address is inadequate to communicate with | system's only IPv6 source address is inadequate to communicate with | |||
off-link destinations even if it did have an off-link route. | off-link destinations even if it did have an off-link route. | |||
Let's examine how the destination address selection mechanism behaves | Let's examine how the destination address selection mechanism behaves | |||
in the face of this scenario when given one IPv4 destination and one | in the face of this scenario when given one IPv4 destination and one | |||
IPv6 destination. | IPv6 destination. | |||
The first rule, "Avoid unusable destinations", could prefer the IPv4 | The first rule, "Avoid unusable destinations", would prefer the IPv4 | |||
destination over the IPv6 destination, but only if the IPv6 | destination over the IPv6 destination, but only if the IPv6 | |||
destination is determined to be unreachable. The unreachability | destination were determined to be unreachable. The unreachability | |||
determination for a destination as it pertains to this rule is an | determination for a destination as it pertains to this rule is an | |||
implementation detail. One implementable method is to do a simple | implementation detail. One implementable method is to do a simple | |||
forwarding table lookup on the destination, and to deem the | forwarding table lookup on the destination, and to deem the | |||
destination as reachable if the lookup succeeds. The Neighbor | destination as reachable if the lookup succeeds. The Neighbor | |||
Discovery on-link assumption mentioned in Section 2.2 makes this | Discovery on-link assumption mentioned in Section 2.2 makes this | |||
method somewhat irrelevant, however, as an implementation of the | method somewhat irrelevant, however, as an implementation of the | |||
assumption could simply be to insert an IPv6 default on-link route | assumption could simply be to insert an IPv6 default on-link route | |||
into the system's forwarding table when the default router list is | into the system's forwarding table when the default router list is | |||
empty. The side-effect is that the rule would always determine that | empty. The side-effect is that the rule would always determine that | |||
all IPv6 destinations are reachable. Therefore, this rule will not | all IPv6 destinations are reachable. Therefore, this rule will not | |||
necessarily prefer one destination over the other. | necessarily prefer one destination over the other. | |||
The second rule, "Prefer matching scope", could prefer the IPv4 | The second rule, "Prefer matching scope", could prefer the IPv4 | |||
destination over the IPv6 destination, but only if the IPv4 | destination over the IPv6 destination, but only if the IPv4 | |||
destination's scope matches the scope of the system's IPv4 source | destination's scope matches the scope of the system's IPv4 source | |||
address. Since [ADDRSEL] considers private addresses (as defined in | address. Since [ADDRSEL] considers private addresses (as defined in | |||
[PRIVADDR]) of site-local scope, then this rule will not prefer | [PRIVADDR]) of site-local scope, then this rule will not prefer | |||
either destination over the other. The link-local IPv6 source | either destination over the other. The link-local IPv6 source | |||
doesn't match the global IPv6 destination, and the site-local IPv4 | doesn't match the global IPv6 destination, and the "site-local" IPv4 | |||
source doesn't match the global IPv4 destination. The tie-breaking | source doesn't match the global IPv4 destination. The tie-breaking | |||
rule in this case is rule 6, "Prefer higher precedence". Since IPv6 | rule in this case is rule 6, "Prefer higher precedence". Since IPv6 | |||
destinations are of higher precedence than IPv4 destinations in the | destinations are of higher precedence than IPv4 destinations in the | |||
default policy table, the IPv6 destination will be preferred. | default policy table, the IPv6 destination will be preferred. | |||
The solution in this case could be to add a new rule after rule 2 | The solution in this case could be to add a new rule after rule 2 | |||
(rule 2.5) that avoids non-link-local IPv6 destinations whose source | (rule 2.5) that avoids non-link-local IPv6 destinations whose | |||
addresses are link-local. Of course, if the host is manually | selected source addresses are link-local. Of course, if the host is | |||
assigned a global IPv6 source address, then rule 2 will automatically | manually assigned a global IPv6 source address, then rule 2 will | |||
prefer the IPv6 destination, and there is no fix other than to make | automatically prefer the IPv6 destination, and there is no fix other | |||
sure rule 1 considers IPv6 destinations unreachable in this scenario. | than to make sure rule 1 considers IPv6 destinations unreachable in | |||
this scenario. | ||||
Fixing the destination address selection mechanism by adding such a | Fixing the destination address selection mechanism by adding such a | |||
rule is only a mitigating factor if applications use standard name | rule is only a mitigating factor if applications use standard name | |||
resolution API's that implement this mechanism, and these | resolution API's that implement this mechanism, and these | |||
applications try addresses in the order returned. This may not be an | applications try addresses in the order returned. This may not be an | |||
acceptable assumption in some cases, as there are applications that | acceptable assumption in some cases, as there are applications that | |||
use hard coded addresses and address search orders (DNS resolver is | use hard coded addresses and address search orders and/or literal | |||
one example), and/or literal addresses passed in from the user. Such | addresses passed in from the user. | |||
applications will obviously be subject to whatever connection delays | ||||
are associated with attempting a connection to an unreachable | For example, one such application is the DNS resolver. In this case, | |||
a configuration file usually contains a list of literal addresses to | ||||
be used as DNS name servers. The resolver client tries these servers | ||||
in the order that they appear in the file, bypassing address | ||||
selection rules. | ||||
Such applications will obviously be subject to whatever connection | ||||
delays are associated with attempting a connection to an unreachable | ||||
destination. This is discussed in more detail in the next few | destination. This is discussed in more detail in the next few | |||
sections. | sections. | |||
2.2 Neighbor Discovery's On-Link Assumption Considered Harmful | 2.2 Neighbor Discovery's On-Link Assumption Considered Harmful | |||
Let's assume that the application described in Section 2 is | Let's assume that the application described in Section 2 is | |||
attempting a connection to an IPv6 address first, either because the | attempting a connection to an IPv6 address first, either because the | |||
destination address selection mechanism described in Section 2.1 | destination address selection mechanism described in Section 2.1 | |||
returned the addresses in that order, or because the application | returned the addresses in that order, or because the application | |||
isn't trying the addresses in the order returned. Regardless, the | isn't trying the addresses in the order returned. Regardless, the | |||
skipping to change at page 5, line 32 | skipping to change at page 5, line 40 | |||
list is empty, then the host assumes that the destination is on-link. | list is empty, then the host assumes that the destination is on-link. | |||
This issue is described in detail in [ONLINK]. In summary, this | This issue is described in detail in [ONLINK]. In summary, this | |||
assumption makes the unreachability detection of off-link nodes in | assumption makes the unreachability detection of off-link nodes in | |||
the absence of a default router a lengthy operation. This is due to | the absence of a default router a lengthy operation. This is due to | |||
the cost of attempting Neighbor Discovery link-layer address | the cost of attempting Neighbor Discovery link-layer address | |||
resolution for each destination, and potential transport layer costs | resolution for each destination, and potential transport layer costs | |||
associated with connection timeouts. The transport layer issues are | associated with connection timeouts. The transport layer issues are | |||
discussed later in Section 2.3. | discussed later in Section 2.3. | |||
On a network that has no IPv6 routing and no IPv6 neighbors, making | On a network that has no IPv6 routing and no IPv6 neighbors, making | |||
the assumption that every IPv6 destination is on-link will be a | the assumption that every IPv6 destination is on-link will be costly | |||
costly and incorrect assumption. If an application has a list of | and incorrect. If an application has a list of addresses associated | |||
addresses associated with a destination and the first 15 are IPv6 | with a destination and the first 15 are IPv6 addresses, then the | |||
addresses, then the application won't be able to successfully send a | application won't be able to successfully send a packet to the | |||
packet to the destination until the attempts to resolve each IPv6 | destination until the attempts to resolve each IPv6 address have | |||
address have failed. This could take 45 seconds | failed. This could take 45 seconds (MAX_MULTICAST_SOLICIT * | |||
(MAX_MULTICAST_SOLICIT * RETRANS_TIMER * 15). This could be | RETRANS_TIMER * 15). This could be compounded by any transport | |||
compounded by any transport timeouts associated with each connection | timeouts associated with each connection attempt, bringing the | |||
attempt. | timeouts to even dozens of minutes. | |||
If IPv6 hosts don't assume that destinations are on-link as described | If IPv6 hosts don't assume that destinations are on-link as described | |||
above, then communication with destinations that are not on-link and | above, then communication with destinations that are not on-link and | |||
unreachable should immediately fail. The IPv6 implementation should | unreachable should immediately fail. The IPv6 implementation should | |||
be able to immediately notify applications or the transport layer | be able to immediately notify applications or the transport layer | |||
that it has no route to such IPv6 destinations, and applications | that it has no route to such IPv6 destinations, so that applications | |||
won't waste time waiting for address resolution to fail. | won't waste time waiting for address resolution to fail. | |||
If hosts need to communicate with on-link destinations in the absence | If hosts need to communicate with on-link destinations in the absence | |||
of default routers, then then they need to be explicitly configured | of default routers, then then they need to be explicitly configured | |||
to have on-link routes for those destinations. | to have on-link routes for those destinations. | |||
2.3 Transport Protocol Robustness | 2.3 Transport Protocol Robustness | |||
Making the same set of assumptions as Section 2.2, regardless of how | Making the same set of assumptions as Section 2.2, regardless of how | |||
long the network layer takes to determine that the IPv6 destination | long the network layer takes to determine that the IPv6 destination | |||
is unreachable, the delay associated with a connection attempt to an | is unreachable, the delay associated with a connection attempt to an | |||
unreachable destination can be compounded by the transport layer. | unreachable destination can be compounded by the transport layer. | |||
When the unreachability of a destination is obviated by the reception | When the unreachability of a destination is obviated by the reception | |||
of an ICMPv6 destination unreachable message, the transport layer | of an ICMPv6 destination unreachable message, the transport layer | |||
should make it possible for the application to deal with this by | should make it possible for the application or API to deal with this. | |||
failing the connection attempt, passing ICMPv6 errors up to the | It could fail the connection attempt, pass ICMPv6 errors up to the | |||
application, etc... Such messages would be received in the cases | application, or pass them up to an API that is handling this for the | |||
mentioned in Section 2 in which a node has no default routers and NUD | application, etc. | |||
fails for destinations assumed to be on-link, and when firewalls or | ||||
other systems that enforce scope boundaries send such ICMPv6 errors | Such messages would be received in the cases mentioned in Section 2 | |||
as described in Section 3.1 and Section 3.3. | in which a node has no default routers and NUD fails for destinations | |||
assumed to be on-link, and when firewalls or other systems that | ||||
enforce scope boundaries send such ICMPv6 errors as described in | ||||
Section 3.1 and Section 3.3. | ||||
For cases when packets to a destination are essentially black-holed | For cases when packets to a destination are essentially black-holed | |||
and no ICMPv6 errors are generated, there is very little additional | and no ICMPv6 errors are generated, there is very little additional | |||
remedy other than the existing timer mechanisms inside transport | remedy other than the existing timer mechanisms inside transport | |||
layers and applications. The following transport layer implication | layers and applications. The following transport layer implication | |||
discussions deal with the former case, in which ICMPv6 errors are | discussions deal with the former case, in which ICMPv6 errors are | |||
received. | received. | |||
2.3.1 TCP Implications | 2.3.1 TCP Implications | |||
In the case of a socket application attempting a connection via TCP, | In the case of a socket application attempting a connection via TCP, | |||
it would be unreasonable for the application to block even after the | it would be unreasonable for the application to block even after the | |||
system has received notification that the destination address is | system has received notification that the destination address is | |||
unreachable via an ICMPv6 Destination Unreachable message. | unreachable via an ICMPv6 Destination Unreachable message. | |||
Following are some ways of solving TCP related delays associated with | Following are some ways of solving TCP related delays associated with | |||
destination unreachability when ICMPv6 errors are generated. | destination unreachability when ICMPv6 errors are generated. | |||
2.3.1.1 TCP Connection Termination | 2.3.1.1 TCP Connection Termination | |||
One solution is for TCP to abort connections in SYN-SENT or | One solution for TCP is to abort connections in SYN-SENT or | |||
SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable | SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable | |||
message. | message. | |||
It should be noted that the Requirements for Internet Hosts | It should be noted that the Requirements for Internet Hosts | |||
[HOSTREQS] document, in section 4.2.3.9., states that TCP MUST NOT | [HOSTREQS] document, in section 4.2.3.9., states that TCP MUST NOT | |||
abort connections when receiving ICMP Destination Unreachable | abort connections when receiving ICMP Destination Unreachable | |||
messages that indicate "soft errors", where soft errors are defined | messages that indicate "soft errors", where soft errors are defined | |||
as ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 | as ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 | |||
(source route failed), and SHOULD abort connections upon receiving | (source route failed), and SHOULD abort connections upon receiving | |||
the other codes (which are considered "hard errors"). ICMPv6 didn't | the other codes (which are considered "hard errors"). ICMPv6 didn't | |||
skipping to change at page 7, line 17 | skipping to change at page 7, line 28 | |||
When [HOSTREQS] was written, most applications would mostly only try | When [HOSTREQS] was written, most applications would mostly only try | |||
one address when establishing communication with a destination. Not | one address when establishing communication with a destination. Not | |||
aborting a connection was a sane thing to do if re-trying a single | aborting a connection was a sane thing to do if re-trying a single | |||
address was a better alternative over quitting the application | address was a better alternative over quitting the application | |||
altogether. With IPv6, and especially on dual stack systems, | altogether. With IPv6, and especially on dual stack systems, | |||
destinations are often assigned multiple addresses (at least one IPv4 | destinations are often assigned multiple addresses (at least one IPv4 | |||
and one IPv6 address), and applications iterate through destination | and one IPv6 address), and applications iterate through destination | |||
addresses when attempting connections. | addresses when attempting connections. | |||
Since soft errors conditions are those that would entice an | Since soft errors conditions are those that would cause an | |||
application to continue iterating to another address, TCP shouldn't | application to continue iterating to another address, TCP could | |||
make the distinction between ICMPv6 soft errors and hard errors when | simply not make the distinction between ICMPv6 soft errors and hard | |||
in SYN-SENT or SYN-RECEIVED state. It should abort a connection in | errors when in SYN-SENT or SYN-RECEIVED state. It would abort a | |||
those states when receiving any ICMPv6 Destination Unreachable | connection in those states when receiving any ICMPv6 Destination | |||
message. When in any other state, TCP would behave as described in | Unreachable message. When in any other state, TCP would behave as | |||
[HOSTREQS]. | described in [HOSTREQS]. | |||
Many TCP implementations already behave this way, but others do not. | Many TCP implementations already behave this way, but others do not. | |||
This should be noted as a best current practice in this case. | This should be noted as a best current practice in this case. | |||
A tangential method of handling the problem in this way would be for | A tangential method of handling the problem in this way would be for | |||
applications to somehow notify the TCP layer of their preference in | applications to somehow notify the TCP layer of their preference in | |||
the matter. An application could notify TCP that it should abort a | the matter. An application could notify TCP that it should abort a | |||
connection upon receipt of particular ICMPv6 errors. Similarly, it | connection upon receipt of particular ICMPv6 errors. Similarly, it | |||
could notify TCP that it should not abort a connection. This would | could notify TCP that it should not abort a connection. This would | |||
allow existing TCP implementations to maintain their status quo at | allow existing TCP implementations to maintain their status quo at | |||
the expense of increased application complexity. | the expense of increased application complexity. | |||
Drawbacks do exist for this TCP behavior. One drawback involves a | ||||
transient problem existing at the network layer that could cause all | ||||
destinations to be unreachable for a temporary length of time. In | ||||
such a situation, the application could quickly cycle through the | ||||
destinations and return an error, when it could have let TCP retry a | ||||
destination a few seconds later when the transient problem could have | ||||
been mitigated. | ||||
Another drawback is related to the insecurity of ICMP messages. | ||||
Reacting to "soft errors" in all TCP connection states would have | ||||
significant security implications, as it would be possible for anyone | ||||
to reset established sessions, even without IP spoofing. However, | ||||
this document only proposes reacting to such errors in SYN-SENT or | ||||
SYN-RECEIVED states. These states are very short-lived, so the | ||||
window of exposure is very short and the threat is negligible. | ||||
2.3.1.2 Asynchronous Application Notification | 2.3.1.2 Asynchronous Application Notification | |||
In section 4.2.4.1, [HOSTREQS] states that there MUST be a mechanism | In section 4.2.4.1, [HOSTREQS] states that there MUST be a mechanism | |||
for reporting soft TCP error conditions to the application. Such a | for reporting soft TCP error conditions to the application. Such a | |||
mechanism (assuming one is implemented) could be used by applications | mechanism (assuming one is implemented) could be used by applications | |||
to cycle through destination addresses. | to cycle through destination addresses. | |||
2.3.1.3 Higher Level API | ||||
Regardless of which solution is used, an API that handles connection | ||||
attempts to a destination in a transparent way could remove the | ||||
complexity from applications and handle this scenario gracefully. The | ||||
API could contain the intelligence required to resolve the hostname, | ||||
try each destination address, etc. | ||||
Such an API would also help to build applications that are protocol | ||||
independent, and would reduce the impact on applications when | ||||
transport layer behavior changes. | ||||
The drawback of this approach is the need to change applications to | ||||
use the API. | ||||
2.3.2 UDP Implications | 2.3.2 UDP Implications | |||
As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST pass | As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST pass | |||
to the application layer all ICMP error messages that it receives | to the application layer all ICMP error messages that it receives | |||
from the IP layer. As a result, proper handling destination | from the IP layer, granted that the socket used is connected. As a | |||
unreachability by UDP applications is the responsibility of the | result, proper handling destination unreachability by UDP | |||
applications themselves. | applications is the responsibility of the applications themselves. | |||
A higher level API as mentioned in Section 2.3.1.3 could remove the | ||||
complexity from applications in this case as well. | ||||
2.3.3 SCTP Implications | 2.3.3 SCTP Implications | |||
According to [SCTPIMP], SCTP ignores all ICMPv6 destination | According to [SCTPIMP], SCTP ignores all ICMPv6 destination | |||
unreachable messages. The existing SCTP specifications do not | unreachable messages that do not indicate that the SCTP protocol | |||
itself is unreachable. The existing SCTP specifications do not | ||||
suggest any action on the part of the implementation on reception of | suggest any action on the part of the implementation on reception of | |||
such messages. Investigation needs to be done to determine the | a "soft error". | |||
implications. | ||||
Unlike TCP, SCTP itself is multihomed and allows a user to specify a | ||||
list of addresses to connect to. Upon reception of a Destination | ||||
Unreachable Message during connection setup SCTP should attempt to | ||||
retransmit the Initiation message to one of its alternate addresses | ||||
and put the address that encountered the "soft error" into the | ||||
unreachable state. This will prevent use of the address after the | ||||
association is set-up until SCTP's heartbeat mechanism finds the | ||||
address to be reachable. | ||||
In some cases the application may not have provided a list of | ||||
addresses. In these cases it may be beneficial for SCTP, at a | ||||
minimum, to mark the address as unreachable so that the application | ||||
can acquire a notification through its application interface. In | ||||
such a case the application could then either take action upon the | ||||
address notification by aborting the connection attempt or allow | ||||
SCTP's normal timer mechanism to continue retransmitting the INIT | ||||
message to the peer's address. | ||||
There is work in progress to specify adding the support for handling | ||||
soft errors to the SCTP specification. | ||||
3. Other Problematic Scenarios | 3. Other Problematic Scenarios | |||
This section describes problems that could arise for a dual stack | This section describes problems that could arise for a dual stack | |||
system with IPv6 enabled when placed on a network with IPv6 | system with IPv6 enabled when placed on a network with IPv6 | |||
connectivity. | connectivity. | |||
3.1 IPv6 Network of Smaller Scope | 3.1 IPv6 Network of Smaller Scope | |||
A network that has a smaller scope of connectivity for IPv6 as it | A network that has a smaller scope of connectivity for IPv6 as it | |||
skipping to change at page 9, line 39 | skipping to change at page 11, line 9 | |||
Disabling IPv6 on the end nodes is another solution. The idea would | Disabling IPv6 on the end nodes is another solution. The idea would | |||
be that enabling IPv6 on dual stack nodes is a manual process that | be that enabling IPv6 on dual stack nodes is a manual process that | |||
would be done when the administrator knows that IPv6 connectivity is | would be done when the administrator knows that IPv6 connectivity is | |||
adequate. | adequate. | |||
3.3 Security | 3.3 Security | |||
Enabling IPv6 on a host implies that the services on the host may be | Enabling IPv6 on a host implies that the services on the host may be | |||
open to IPv6 communication. If the service itself is insecure and | open to IPv6 communication. If the service itself is insecure and | |||
depends on security policy enforced somewhere else on the network | depends on a security policy enforced somewhere else on the network | |||
(such as in a firewall), then there is potential for new attacks | (such as in a firewall), then there is potential for new attacks | |||
against the service. | against the service. | |||
A firewall, for example, may not be enforcing the same policy for | A firewall may not be enforcing the same policy for IPv4 as for IPv6 | |||
IPv4 as for IPv6 traffic. One possibility is that the firewall could | traffic, which could be due to misconfiguration of the firewall. One | |||
have more relaxed policy for IPv6, perhaps by letting all IPv6 | possibility is that the firewall could have more relaxed policy for | |||
packets pass through, or by letting all IPv4 protocol 41 packets pass | IPv6, perhaps by letting all IPv6 packets pass through, or by letting | |||
through. In this scenario, the dual stack hosts within the protected | all IPv4 protocol 41 packets pass through. In this scenario, the | |||
network could be subject to different attacks than for IPv4. | dual stack hosts within the protected network could be subject to | |||
different attacks than for IPv4. | ||||
Even if a firewall has a stricter policy or identical policy for IPv6 | Even if a firewall has a stricter policy or identical policy for IPv6 | |||
traffic than for IPv4 (the extreme case being that it drops all IPv6 | traffic than for IPv4 (the extreme case being that it drops all IPv6 | |||
traffic), IPv6 packets could go through the network untouched if | traffic), IPv6 packets could go through the network untouched if | |||
tunneled over a transport layer. This could open the host to direct | tunneled over a transport layer. This could open the host to direct | |||
IPv6 attacks. | IPv6 attacks. It should be noted that IPv4 packets can also be | |||
tunneled, so this is not a new security concern for IPv6. Firewalls | ||||
must be deliberately and properly configured. | ||||
A similar problem could exist for VPN software. A VPN could protect | A similar problem could exist for virtual private network (VPN) | |||
all IPv4 packets but transmit all others onto the local subnet | software. A VPN could protect all IPv4 packets but transmit all | |||
unprotected. At least one widely used VPN behaves this way. This is | others onto the local subnet unprotected. At least one widely used | |||
problematic on a dual stack host that has IPv6 enabled on its local | VPN behaves this way. This is problematic on a dual stack host that | |||
network. It establishes its VPN link and attempts to communicate | has IPv6 enabled on its local network. It establishes its VPN link | |||
with destinations that resolve to both IPv4 and IPv6 addresses. The | and attempts to communicate with destinations that resolve to both | |||
destination address selection mechanism prefers the IPv6 destination | IPv4 and IPv6 addresses. The destination address selection mechanism | |||
so the application sends packets to an IPv6 address. The VPN doesn't | prefers the IPv6 destination so the application sends packets to an | |||
know about IPv6, so instead of protecting the packets and sending | IPv6 address. The VPN doesn't know about IPv6, so instead of | |||
them to the remote end of the VPN, it passes such packets in the | protecting the packets and sending them to the remote end of the VPN, | |||
clear to the local network. The reason that packets meant to be | it passes such packets in the clear to the local network. | |||
protected would be sent in the clear on the local network is either | ||||
because of the on-link assumption discussed in Section 2.2, or of | This is problematic for a number of reasons. The first is that if | |||
malicious hijacking of traffic by a rogue "fake" router advertising a | the node has a default IPv6 route, the packets will be forwarded | |||
prefix. | off-link to an unknown destination. Another is if no legitimate | |||
router is on-link and the node makes the on-link assumption discussed | ||||
in Section 2.2, the packets will simply be sent onto the local link | ||||
to be potentially viewed by a node spoofing the destination. A third | ||||
is if a rogue IPv6 router exists on-link. In that case the malicious | ||||
node will simply be sent all IPv6 packets in the clear. | ||||
3.3.1 Mitigating Security Risks | 3.3.1 Mitigating Security Risks | |||
The security policy implemented in firewalls, VPN software, or other | The security policy implemented in firewalls, VPN software, or other | |||
devices, must take a stance whether it applies equally to both IPv4 | devices, must take a stance whether it applies equally to both IPv4 | |||
and IPv6 traffic. It is probably desirable for policy to apply | and IPv6 traffic. It is probably desirable for the policy to apply | |||
equally to both IPv4 and IPv6, but the most important thing is to be | equally to both IPv4 and IPv6, but the most important thing is to be | |||
aware of the potential problem, and to make the policy clear to the | aware of the potential problem, and to make the policy clear to the | |||
administrator and user. | administrator and user. | |||
There is still a risk that IPv6 packets could be tunneled over a | There is still a risk that IPv6 packets could be tunneled over a | |||
transport layer such as UDP, implicitly bypassing security policy. | transport layer such as UDP, implicitly bypassing the security | |||
Some more complex mechanism could be implemented to apply the correct | policy. Some more complex mechanisms could be implemented to apply | |||
policy to such packets. This could be easy to do if tunnel endpoints | the correct policy to such packets. This could be easy to do if | |||
are co-located with a firewall, but more difficult if internal nodes | tunnel endpoints are co-located with a firewall, but more difficult | |||
do their own IPv6 tunneling. | if internal nodes do their own IPv6 tunneling. | |||
4. Application Robustness | 4. Application Robustness | |||
Enabling IPv6 on a dual stack node is only useful if applications | Enabling IPv6 on a dual stack node is only useful if applications | |||
that support IPv6 on that node properly cycle through addresses | that support IPv6 on that node properly cycle through addresses | |||
returned from name lookups and fall back to IPv4 when IPv6 | returned from name lookups and fall back to IPv4 when IPv6 | |||
communication fails. Simply cycling through the list of addresses | communication fails. Simply cycling through the list of addresses | |||
returned from a name lookup when attempting connections works in most | returned from a name lookup when attempting connections works in most | |||
cases for most applications, but there are still cases where that's | cases for most applications, but there are still cases where that's | |||
not enough. Applications also need to be aware that the fact that a | not enough. Applications also need to be aware that the fact that a | |||
dual stack destination's IPv6 address is published in the DNS does | dual stack destination's IPv6 address is published in the DNS does | |||
not necessarily imply that all services on that destination function | not necessarily imply that all services on that destination function | |||
over IPv6. This problem, along with a thorough discussion of IPv6 | over IPv6. This problem, along with a thorough discussion of IPv6 | |||
application transition guidelines, is discussed in [APPTRANS]. | application transition guidelines, is discussed in [APPTRANS]. | |||
5. Security Considerations | 5. Security Considerations | |||
This document raises security concerns in Section 3.3. | This document raises security concerns in Section 3.3. They are | |||
summarized below: | ||||
Normative References | o Firewalls need to be configured properly to have deliberate | |||
security policies for IPv6 packets, including IPv6 packets | ||||
encapsulated in other layers. | ||||
o Implementations of virtual private networks need to have a | ||||
deliberate IPv6 security policy that doesn't allow packets to | ||||
accidentally appear in the clear when they were intended to be | ||||
sent securely over the VPN. | ||||
6. References | ||||
6.1 Normative References | ||||
[ADDRSEL] Draves, R., "Default Address Selection for Internet | [ADDRSEL] Draves, R., "Default Address Selection for Internet | |||
Protocol version 6 (IPv6)", RFC 3484, February 2003. | Protocol version 6 (IPv6)", RFC 3484, February 2003. | |||
[APPTRANS] | [APPTRANS] | |||
Hong, Y-G., Hagino, J., Savola, P. and M. Castro, | Hong, Y-G., Hagino, J., Savola, P. and M. Castro, | |||
"Application Aspects of IPv6 Transition", October 2003. | "Application Aspects of IPv6 Transition", March 2004. | |||
draft-ietf-v6ops-application-transition-00 | draft-ietf-v6ops-application-transition-02 | |||
[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor | [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor | |||
Discovery for IP Version 6 (IPv6)", RFC 2461, December | Discovery for IP Version 6 (IPv6)", RFC 2461, December | |||
1998. | 1998. | |||
[ONLINK] Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery | [ONLINK] Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery | |||
On-Link Assumption Considered Harmful", October 2003. | On-Link Assumption Considered Harmful", October 2003. | |||
draft-ietf-v6ops-onlinkassumption-00 | draft-ietf-v6ops-onlinkassumption-02 | |||
Informative References | 6.2 Informative References | |||
[AUTOCONF] | [AUTOCONF] | |||
Thomson, S. and T. Narten, "IPv6 Stateless Address | Thomson, S. and T. Narten, "IPv6 Stateless Address | |||
Autoconfiguration", RFC 2462, December 1998. | Autoconfiguration", RFC 2462, December 1998. | |||
[HOSTREQS] | [HOSTREQS] | |||
Braden, R., "Requirements for Internet Hosts -- | Braden, R., "Requirements for Internet Hosts -- | |||
Communication Layers", STD 3, RFC 1122, October 1989. | Communication Layers", STD 3, RFC 1122, October 1989. | |||
[PRIVADDR] | [PRIVADDR] | |||
skipping to change at page 12, line 34 | skipping to change at page 14, line 23 | |||
Sun Microsystems, Inc. | Sun Microsystems, Inc. | |||
17 Network Circle | 17 Network Circle | |||
UMPK17-202 | UMPK17-202 | |||
Menlo Park, CA 94025 | Menlo Park, CA 94025 | |||
EMail: james.paugh@sun.com | EMail: james.paugh@sun.com | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
The authors gratefully acknowledge the contributions of Jim Bound, | The authors gratefully acknowledge the contributions of Jim Bound, | |||
Tim Hartrick, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald | Fernando Gont, Tony Hain, Tim Hartrick, Mika Liljeberg, Erik | |||
Nordmark, Kacheong Poon, Pekka Savola, Randall Stewart, and Ronald | ||||
van der Pol. | van der Pol. | |||
Appendix B. Changes from draft-ietf-v6ops-v6onbydefault-00 | Appendix B. Changes from draft-ietf-v6ops-v6onbydefault-01 | |||
o Added specificity to the DNS resolver problem in Section 2.1. | ||||
o Added a few paragraphs in Section 2.3.1.1 describing potential | ||||
drawbacks to TCP aborting connections ins SYN-SENT or SYN-RECEIVED | ||||
state. | ||||
o Added Section 2.3.1.3 describing how a higher level API could be | ||||
used to manage connections. | ||||
o Expanded Section 2.3.3 to describe desired SCTP behavior when | ||||
encountering soft errors. | ||||
o Added a summary of security concerns to Section 5. | ||||
o Miscellaneous editorial changes. | ||||
Appendix C. Changes from draft-ietf-v6ops-v6onbydefault-00 | ||||
o Clarified in the abstract and introduction that the document is | o Clarified in the abstract and introduction that the document is | |||
meant to raise awareness, and not to specify whether IPv6 should | meant to raise awareness, and not to specify whether IPv6 should | |||
be enabled by default or not. | be enabled by default or not. | |||
o Shortened section Section 2.2 and made reference to [ONLINK]. | o Shortened Section 2.2 and made reference to [ONLINK]. | |||
o Added clarification in section Section 2.3 about packets that are | o Added clarification in Section 2.3 about packets that are lost | |||
lost without ICMPv6 notification. | without ICMPv6 notification. | |||
o Section Section 2.3 now has subsections for TCP, UDP, and SCTP. | o Section 2.3 now has subsections for TCP, UDP, and SCTP. | |||
o Removed text in Section 2.3.1.1 suggesting that hosts usually were | o Removed text in Section 2.3.1.1 suggesting that hosts usually were | |||
only assigned one address when [HOSTREQS] was written. | only assigned one address when [HOSTREQS] was written. | |||
o Added text in Section 2.3.1.1 suggesting a method for applications | o Added text in Section 2.3.1.1 suggesting a method for applications | |||
to advise TCP of their preference for ICMPv6 handling. | to advise TCP of their preference for ICMPv6 handling. | |||
o Added section Section 2.3.1.2. | o Added Section 2.3.1.2. | |||
o Added section Section 2.3.2. | o Added Section 2.3.2. | |||
o Added section Section 2.3.3. | o Added Section 2.3.3. | |||
o Strengthened wording in section Section 3.1.1 to suggest that | o Strengthened wording in Section 3.1.1 to suggest that devices | |||
devices enforcing scope boundaries must send ICMPv6 Destination | enforcing scope boundaries must send ICMPv6 Destination | |||
Unreachable messages. | Unreachable messages. | |||
o Clarified that the VPN problem described in Section 3.3 is due to | o Clarified that the VPN problem described in Section 3.3 is due to | |||
a combination of the VPN software and either the on-link | a combination of the VPN software and either the on-link | |||
assumption and/or a "bad guy". | assumption and/or a "bad guy". | |||
o Shortened section Section 4 and made reference to [APPTRANS]. | o Shortened Section 4 and made reference to [APPTRANS]. | |||
o Miscellaneous editorial changes. | o Miscellaneous editorial changes. | |||
Intellectual Property Statement | Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
intellectual property or other rights that might be claimed to | intellectual property or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; neither does it represent that it | might or might not be available; neither does it represent that it | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |