diff options
Diffstat (limited to 'doc/rfc/rfc6343.txt')
| -rw-r--r-- | doc/rfc/rfc6343.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc6343.txt b/doc/rfc/rfc6343.txt new file mode 100644 index 0000000..a11f43c --- /dev/null +++ b/doc/rfc/rfc6343.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Carpenter +Request for Comments: 6343 Univ. of Auckland +Category: Informational August 2011 +ISSN: 2070-1721 + + + Advisory Guidelines for 6to4 Deployment + +Abstract + + This document provides advice to network operators about deployment + of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It + is principally addressed to Internet Service Providers (ISPs), + including those that do not yet support IPv6, and to Content + Providers. Some advice to implementers is also included. The + intention of the advice is to minimize both user dissatisfaction and + help-desk calls. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6343. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Carpenter Informational [Page 1] + +RFC 6343 6to4 Advisory August 2011 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Principles of Operation .........................................3 + 2.1. Router 6to4 ................................................3 + 2.2. Anycast 6to4 ...............................................4 + 3. Problems Observed ...............................................5 + 4. Advisory Guidelines ............................................10 + 4.1. Vendor Issues .............................................10 + 4.2. Consumer ISPs, and Enterprise Networks, That Do + Not Support IPv6 in Any Way ...............................11 + 4.2.1. Anycast Address Availability .......................11 + 4.2.2. Protocol 41 ........................................11 + 4.2.3. IPv4 Prefix Issues .................................12 + 4.2.4. DNS Issues .........................................12 + 4.2.5. Rogue Router Advertisements ........................12 + 4.2.6. Planning for IPv6 Deployment .......................13 + 4.3. Consumer ISPs, and Enterprise Networks, That Do + Support IPv6 ..............................................13 + 4.4. Transit ISPs and Internet Exchange Points .................14 + 4.5. Content Providers and Their ISPs ..........................15 + 5. Tunnels Managed by ISPs ........................................17 + 6. Security Considerations ........................................17 + 7. Acknowledgements ...............................................18 + 8. References .....................................................18 + 8.1. Normative References ......................................18 + 8.2. Informative References ....................................18 + +1. Introduction + + A technique for automatic tunneling of IPv6 over IPv4, intended for + situations where a user may wish to access IPv6-based services via a + network that does not support IPv6, was defined a number of years + ago. It is known as 6to4 [RFC3056] [RFC3068] and is quite widely + deployed in end systems, especially desktop and laptop computers. + Also, 6to4 is supported in a number of popular models of CPE routers, + some of which have it enabled by default, leading to quite widespread + unintentional deployment by end users. + + Unfortunately, experience shows that the method has some problems in + current deployments that can lead to connectivity failures. These + failures cause either long retry delays or complete failures for + users trying to connect to services. In many cases, the user may be + quite unaware that 6to4 is in use; when the user contacts a help + desk, in all probability the help desk is unable to correctly + diagnose the problem. Anecdotally, many help desks simply advise + users to disable IPv6, thus defeating the whole purpose of the + mechanism, which was to encourage early adoption of IPv6. + + + +Carpenter Informational [Page 2] + +RFC 6343 6to4 Advisory August 2011 + + + The main goal of the present document is to offer advice to network + operators on how to deal with this situation more constructively than + by disabling 6to4. It briefly describes the principle of operation, + then describes the problems observed, and finally offers specific + advice on the available methods of avoiding the problems. Note that + some of this advice applies to ISPs that do not yet support IPv6, + since their customers and help desks are significantly affected in + any case. + + Other advice applies to content providers and implementers, but this + document does not discuss aspects that are mainly outside the scope + of network operators: + + 1. Operating system preferences between IPv4 and IPv6 when both + appear to be available [RFC3484-REVISE]. + + 2. Ensuring that application software deals gracefully with + connectivity problems [EYEBALLS-IPV6]. + + 3. Some content providers have chosen to avoid the problem by hiding + their IPv6 address except from customers of pre-qualified + networks [DNSWHITE]. + + A companion document [HISTORIC] proposes to reclassify 6to4 as + Historic. However, this will not remove the millions of existing + hosts and CPEs that implement 6to4. Hence, the advice in this + document remains necessary. + +2. Principles of Operation + + There are two variants of 6to4 that are referred to here as "Router + 6to4" and "Anycast 6to4". To understand Anycast 6to4, it is + necessary first to understand Router 6to4. + +2.1. Router 6to4 + + Router 6to4 is the original version, documented in [RFC3056]. The + model assumes that a user site operates native IPv6, but that its ISP + provides no IPv6 service. The site border router acts as a 6to4 + router. If its external global 32-bit IPv4 address is V4ADDR, the + site automatically inherits the IPv6 prefix 2002:V4ADDR::/48. (The + explanation in RFC 3056 is somewhat confusing, as it refers to the + obsolete "Top Level Aggregator" terminology.) The prefix 2002: + V4ADDR::/48 will be used and delegated for IPv6 service within the + user site. + + + + + + +Carpenter Informational [Page 3] + +RFC 6343 6to4 Advisory August 2011 + + + Consider two such site border routers, with global IPv4 addresses + 192.0.2.170 and 192.0.2.187, and that therefore inherit the IPv6 + prefixes 2002:c000:2aa::/48 and 2002:c000:2bb::/48, respectively. + The routers can exchange IPv6 packets by encapsulating them in IPv4 + using protocol number 41, and sending them to each other at their + respective IPv4 addresses. In fact, any number of 6to4 routers + connected to the IPv4 network can directly exchange IPv6 packets in + this way. + + Some 6to4 routers are also configured as "relay routers". They + behave as just described, but, in addition, they obtain native IPv6 + connectivity with a normal IPv6 prefix. They announce an IPv6 route + to 2002::/16. For example, assume that the 6to4 router at + 192.0.2.187 is a relay router, whose address on the 6to4 side is + 2002:c000:2bb::1. Suppose that a host with the 6to4 address 2002: + c000:2aa::123 sends an IPv6 packet to a native IPv6 destination such + as 2001:db8:123:456::321. Assume that the 6to4 router at 192.0.2.170 + has its IPv6 default route set to 2002:c000:2bb::1, i.e., the relay. + The packet will be delivered to the relay, encapsulated in IPv4. The + relay will decapsulate the packet and forward it into native IPv6 for + delivery. When the remote host replies, the packet (source 2001:db8: + 123:456::321, destination 2002:c000:2aa::123) will find a route to + 2002::/16, and hence be delivered to a 6to4 relay. The process will + be reversed and the packet will be encapsulated and forwarded to the + 6to4 router at 192.0.2.170 for final delivery. + + Note that this process does not require the same relay to be used in + both directions. The outbound packet will go to whichever relay is + configured as the default IPv6 router at the source router, and the + return packet will go to whichever relay is announcing a route to + 2002::/16 in the vicinity of the remote IPv6 host. + + Of course, there are many further details in RFC 3056, most of which + are irrelevant to current operational problems. + +2.2. Anycast 6to4 + + Router 6to4 assumes that 6to4 routers and relays will be managed and + configured cooperatively. In particular, 6to4 sites need to + configure a relay router willing to carry their outbound traffic, + which becomes their default IPv6 router (except for 2002::/16). The + objective of the anycast variant, defined in [RFC3068], is to avoid + any need for such configuration. The intention was to make the + solution available for small or domestic users, even those with a + single host or simple home gateway rather than a border router. This + is achieved quite simply, by defining 192.88.99.1 as the default IPv4 + address for a 6to4 relay, and therefore 2002:c058:6301:: as the + default IPv6 router address for a 6to4 site. + + + +Carpenter Informational [Page 4] + +RFC 6343 6to4 Advisory August 2011 + + + Since Anycast 6to4 implies a default configuration for the user site, + it does not require any particular user action. It does require an + IPv4 anycast route to be in place to a relay at 192.88.99.1. As with + Router 6to4, there is no requirement that the return path goes + through the same relay. + +3. Problems Observed + + It should be noted that Router 6to4 was not designed to be an + unmanaged solution. Quite the contrary: RFC 3056 contains a number + of operational recommendations intended to avoid routing issues. In + practice, there are few if any deployments of Router 6to4 following + these recommendations. Mostly, Anycast 6to4 has been deployed. In + this case, the user site (either a single host or a small broadband + gateway) discovers that it doesn't have native IPv6 connectivity, but + that it does have a global IPv4 address and can resolve AAAA queries. + Therefore, it assumes that it can send 6to4 packets to 192.88.99.1. + + Empirically, 6to4 appears to suffer from a significant level of + connection failure; see [Aben] and [Huston-a]. In experiments + conducted on a number of dual-stack web servers, the TCP connection + failure rate has been measured. In these experiments, the client's + connection attempt to a server was considered to have failed when the + server received a TCP SYN packet and sent a SYN/ACK packet in + response, but received no ACK packet to complete the initial TCP + three-way handshake. The experiment conducted by Aben recorded a + failure rate of between 9% and 20% of all 6to4 connection attempts. + The experiment conducted by Huston has recorded a failure rate of + between 9% and 19% of all 6to4 clients. In this latter experiment, + it was further noted that between 65% to 80% of all 6to4 clients who + failed to connect using 6to4 were able to make a successful + connection using IPv4, while the remainder did not make any form of + IPv4 connection attempt, successful or otherwise, using the mapped + IPv4 address as a source address. No connection attempts using + embedded RFC 1918 IPv4 addresses were recorded by the server. + + There have been several possible reasons offered for this form of + 6to4 connection failure. One is the use of private IPv4 addresses + embedded in the 6to4 address, making the return path for the 6to4 + tunnel infeasible, and the second is the use of local filters and + firewalls that drop incoming IP packets that use IP protocol 41. If + the former case were prevalent, it would be reasonable to expect that + a significant proportion of failed 6to4 connections would use + embedded IPv4 addresses that are either drawn from the private use + (RFC 1918) address ranges, contrary to RFC 3056, or from addresses + that are not announced in the Internet's IPv4 inter-domain routing + table. Neither case was observed to any significant volume in the + experiments conducted by Huston. Furthermore, the experimental + + + +Carpenter Informational [Page 5] + +RFC 6343 6to4 Advisory August 2011 + + + conditions were varied to use a return 6to4 tunnel with either the + native IPv4 source address of the dual-stack server or an IPv4 source + address of 192.88.99.1. No change in the 6to4 connection failure + rate was observed between these two configurations; however, other + operators have reported significant problems when replying from the + native address, caused by stateful firewalls at the user site. Given + that the server used its own 6to4 relay for the return path, the only + difference in the IP packet itself between the successful IPv4 + connections and the failed 6to4 connections was the IP protocol + number, which was 6 (TCP) for the successful IPv4 connections and 41 + (IPv6 payload) for the failed 6to4 connections. The inference from + these experiments is that one likely reason for the high connection + failure rate for 6to4 connections is the use of local filters close + to the end user that block incoming packets with protocol 41, in some + cases made worse by stateful firewalls if the source address is not + 192.88.99.1. + + In a dual-stack context, this connection failure rate was effectively + masked by the ability of the client system to recover from the + failure and make a successful connection using IPv4. In this case, + the only effect on the client system was a delay in making the + connection of between 7 and 20 seconds as the client's system timed + out on the 6to4 connection attempts (see [EYEBALLS-IPV6]). + + This experience, and further analysis, shows that specific + operational problems with Anycast 6to4 include: + + 1. Outbound Black Hole: 192.88.99.1 does not generate 'destination + unreachable' but in fact packets sent to that address are + dropped. This can happen due to routing or firewall + configuration, or even because the relay that the packets happen + to reach contains an ACL such that they are discarded. + + This class of problem arises because the user's ISP is accepting + a route to 192.88.99.0/24 despite the fact that it doesn't go + anywhere useful. Either the user site or its ISP is dropping + outbound protocol 41 traffic, or the upstream operator is + unwilling to accept incoming 6to4 packets from the user's ISP. + The latter is superficially compatible with the design of Router + 6to4 (referred to as "unwilling to relay" in RFC 3056). However, + the simple fact of announcing a route to 192.88.99.0/24 in IPv4, + coupled with the behavior described in RFC 3068, amounts to + announcing a default route for IPv6 to all 6to4 sites that + receive the IPv4 route. This violates the assumptions of RFC + 3056. + + + + + + +Carpenter Informational [Page 6] + +RFC 6343 6to4 Advisory August 2011 + + + The effect of this problem on users is that their IPv6 stack + believes that it has 6to4 connectivity, but in fact all outgoing + IPv6 packets are black-holed. The prevalence of this problem is + hard to measure, since the resulting IPv6 packets can never be + observed from the outside. + + 2. Inbound Black Hole: In this case, 6to4 packets sent to + 192.88.99.1 are correctly delivered to a 6to4 relay, and reply + packets are returned, but they are dropped by an inbound protocol + 41 filter. As far as the user is concerned, the effect is the + same as the previous case: IPv6 is a black hole. Many enterprise + networks are believed to be set up in this way. Connection + attempts due to this case can be observed by IPv6 server + operators, in the form of SYN packets from addresses in 2002::/16 + followed by no response to the resulting SYN/ACK. From the + experiments cited above, this appears to be a significant problem + in practice. + + This problem is complicated by three variables: the firewall + applying the protocol 41 filter may be stateless or stateful; the + relay may source its packets from its native IPv4 address or from + 192.88.99.1; packets from the relay may be subject to IPv4 + ingress filtering. If the protocol 41 filter is stateless, 6to4 + will never succeed. If it is stateful, the firewall will drop + inbound packets from addresses that have not been seen in + outbound traffic on the same port. In this case, 6to4 will only + succeed if the packets are sourced from 192.88.99.1. If the + relay is subject to ingress filtering, only packets from its + native IPv4 address can be transmitted. Therefore, there are + only three combinations that can succeed: + + 1. No protocol 41 filter, with the relay using its native IPv4 + source address. + + 2. No protocol 41 filter, with the relay using the anycast IPv4 + source address and with no ingress filter. + + 3. A stateful protocol 41 firewall, with the relay using the + anycast IPv4 source address and with no ingress filter. + + 3. No Return Relay: If the Outbound Black Hole problem does not + occur, i.e., the outgoing packet does reach the intended native + IPv6 destination, the target system will send a reply packet, to + 2002:c000:2aa::123 in our example above. Then, 2002::/16 may or + may not be successfully routed. If it is not routed, the packet + will be dropped (hopefully, with 'destination unreachable'). + According to RFC 3056, an unwilling relay "MUST NOT advertise any + 2002:: routing prefix into the native IPv6 domain"; therefore, + + + +Carpenter Informational [Page 7] + +RFC 6343 6to4 Advisory August 2011 + + + conversely, if this prefix is advertised the relay must relay + packets regardless of source and destination. However, in + practice, the problem arises that some relays reject packets that + they should relay, based on their IPv6 source address. + + Whether the native IPv6 destination has no route to 2002::/16 or + it turns out to have a route to an unwilling relay, the effect is + the same: all return IPv6 packets are black-holed. While there + is no direct evidence of the prevalence of this problem, it + certainly exists in practice. + + 4. Large RTT: In the event that none of the above three problems + applies, and a two-way path does in fact exist between a 6to4 + host and a native host, the round-trip time may be quite large + and variable since the paths to the two relays are unmanaged and + may be complex. Overloaded relays might also cause highly + variable RTT. + + 5. PMTUD Failure: A common link MTU size observed on the Internet + today is 1500 bytes. However, when using 6to4, the path MTU is + less than this due to the encapsulation header. Thus, a 6to4 + client will normally see a link MTU that is less than 1500, but a + native IPv6 server will see 1500. It has been observed that Path + MTU Discovery (PMTUD) does not always work, and this can lead to + connectivity failures. Even if a TCP SYN/ACK exchange works, TCP + packets with full-size payloads may simply be lost. This problem + is apparently exacerbated in some cases by failure of the TCP + Maximum Segment Size (MSS) negotiation mechanism [RFC2923]. + These failures are disconcerting even to an informed user, since + a standard 'ping' from the client to the server will succeed, + because it generates small packets, and the successful SYN/ACK + exchange can be traced. Also, the failure may occur on some + paths but not others, so a user may be able to fetch web pages + from one site, but only ping another. + + Additionally, there is a problem if 6to4 is enabled on a router + and it advertises the resulting prefix on a LAN, but does not + also advertise a smaller MTU; in this case, TCP MSS negotiation + will definitely fail. + + 6. Reverse DNS Failure: Typically, a 6to4-addressed host will not + have a reverse DNS delegation. If reverse DNS is used as a + pseudo-security check, it will fail. + + 7. Bogus Address Failure: By design, 6to4 does not work and will not + activate itself if the available V4ADDR is a private address + [RFC1918]. However, it will also not work if the available + V4ADDR is a "bogon", i.e., a global address that is being used by + + + +Carpenter Informational [Page 8] + +RFC 6343 6to4 Advisory August 2011 + + + the operator as a private address. A common case of this is a + legacy wireless network using 1.1.1.0/24 as if it was a private + address. In this case, 6to4 will assume it is connected to the + global Internet, but there is certainly no working return path. + + This failure mode will also occur if an ISP is operating a + Carrier Grade NAT [CGN] between its customers and the Internet, + and is using global public address space as if it were private + space to do so. + + 8. Faulty 6to4 Implementations: It has been reported that some 6to4 + implementations attempt to activate themselves even when the + available IPv4 address is an RFC 1918 address. This is in direct + contradiction to RFC 3056, and will produce exactly the same + failure mode as Bogus Address Failure. It is of course outside + the ISP's control. + + 9. Difficult Fault Diagnosis: The existence of all the above failure + modes creates a problem of its own: very difficult fault + diagnosis, especially if the only symptom reported by a user is + slow access to web pages, caused by a long timeout before + fallback to IPv4. Tracking down anycast routing problems and + PMTUD failures is particularly hard. + + The practical impact of the above problems, which are by no means + universal as there is considerable successful use of Anycast 6to4, + has been measured at a fraction of 1% loss of attempted connections + to dual-stack content servers [Anderson]. This is because a small + fraction of client hosts attempt to connect using 6to4, and up to 20% + of these experience one of the above failure modes. While this seems + low, it amounts to a significant financial impact for content + providers. Also, end users frustrated by the poor response times + caused by fallback to IPv4 connectivity [EYEBALLS-IPV6] are + considered likely to generate help-desk calls with their attendant + costs. + + A rather different operational problem caused incidentally by 6to4 is + that, according to observations made at the University of Southampton + by Tim Chown and James Morse, and at other sites, rogue Router + Advertisements [RFC6104] often convey a 2002::/16 prefix. This + appears to be due to misbehavior by devices acting as local IPv6 + routers or connection-sharing devices but issuing Router + Advertisement (RA) messages on the wrong interface. Such a device, + if it obtains IPv6 connectivity via an upstream link to the Internet, + should only issue the corresponding RA messages on its downstream + link to the nodes intended to share its Internet connection. Issuing + RA messages on the upstream link will perturb any other IPv6 hosts on + + + + +Carpenter Informational [Page 9] + +RFC 6343 6to4 Advisory August 2011 + + + that link. If 6to4 routing is enabled by default on a device that + exhibits this faulty behavior, the resulting rogue RA messages will + indeed convey a 2002::/16 prefix. + +4. Advisory Guidelines + + There are several types of operator involved, willingly or + unwillingly, in the Anycast 6to4 scenario and they will all suffer if + things work badly. To avoid operational problems and customer + dissatisfaction, there is a clear incentive for each of them to take + appropriate action, as described below. + + This document avoids formal normative language, because it is highly + unlikely that the guidelines apply universally. Each operator will + make its own decisions about which of the following guidelines are + useful in its specific scenario. + +4.1. Vendor Issues + + Although this document is aimed principally at operators, there are + some steps that implementers and vendors of 6to4 should take. + + 1. Some vendors of routers, including customer premises equipment, + have not only included support for 6to4 in their products, but + have enabled it by default. This is bad practice - it should + always be a conscious decision by a user to enable 6to4. Many of + the above problems only occur due to unintentional deployment of + 6to4. + + 2. Similarly, host operating systems should not enable Anycast 6to4 + by default; it should always be left to the user to switch it on. + + 3. Any 6to4 implementation that attempts to activate itself when the + available IPv4 address is an RFC 1918 address is faulty and needs + to be updated. + + 4. 6to4 implementations should adopt updated IETF recommendations on + address selection [RFC3484-REVISE]. + + 5. 6to4 relay implementations must carefully follow Section 3.2 of + [RFC4213] to ensure correct handling of MTU issues. + + 6. 6to4 router or connection-sharing implementations must avoid + issuing rogue RAs [RFC6104]. Additionally, where 6to4 is being + enabled by a node for Internet-connection-sharing purposes, and + the node supports [RFC4191], then it should set the Router + Advertisement router preference bits to 11 (low preference). + + + + +Carpenter Informational [Page 10] + +RFC 6343 6to4 Advisory August 2011 + + +4.2. Consumer ISPs, and Enterprise Networks, That Do Not Support IPv6 + in Any Way + +4.2.1. Anycast Address Availability + + To reduce the negative impact of Anycast 6to4 deployed (probably + unknowingly) by users, and consequent user dissatisfaction and help- + desk calls, such ISPs should check in sequence: + + 1. Does the ISP have a route to 192.88.99.1? (This means an + explicit route, or knowledge that the default upstream provider + has an explicit route. A default route doesn't count!) + + 2. If so, is it functional and stable? + + 3. If so, is the ping time reasonably short? + + 4. If so, does the relay willingly accept 6to4 traffic from the + ISP's IPv4 prefixes? (Note that this is an administrative as + well as a technical question -- is the relay's operator willing + to accept the traffic?) + + Unless the answer to all these questions is 'yes', the operator + should consider blocking the route to 192.88.99.1 and generating an + IPv4 'destination unreachable' message. This may cause some 6to4 + implementations to fall back to IPv4 more quickly. There is little + operational experience with this, however. + + Some implementations also perform some form of 6to4 relay + qualification. For example, one host implementation (Windows) tests + the protocol 41 reachability by sending an ICMPv6 echo request with + Hop Limit = 1 to the relay, expecting a response or Hop Limit + exceeded error back. Lack of any response indicates that the 6to4 + relay does not work so 6to4 is turned off [Savola]. + + A more constructive approach for such an ISP is to seek out a transit + provider who is indeed willing to offer outbound 6to4 relay service, + so that the answer to each of the questions above is positive. + +4.2.2. Protocol 41 + + ISPs in this class should always allow protocol 41 through their + network and firewalls. Not only is this a necessary condition for + 6to4 to work, but it also allows users who want to use a configured + IPv6 tunnel service to do so. + + + + + + +Carpenter Informational [Page 11] + +RFC 6343 6to4 Advisory August 2011 + + + Some operators, particularly enterprise networks, silently block + protocol 41 on security grounds. Doing this on its own is bad + practice, since it contributes to the problem and harms any users who + are knowingly or unknowingly attempting to run 6to4. The strategic + solution is to deploy native IPv6, making protocol 41 redundant. In + the short term, experimentation could be encouraged by allowing + protocol 41 for certain users, while returning appropriate ICMP + responses as mentioned above. Unfortunately, if this is not done, + the 6to4 problem cannot be solved. + +4.2.3. IPv4 Prefix Issues + + Operators should never use "bogon" address space such as the example + of 1.1.1.0/24 for customers, since IPv4 exhaustion means that all + such addresses are likely to be in real use in the near future. + (Also, see [RFC6269].) An operator that is unable to immediately + drop this practice should ensure that 192.88.99.1 generates IPv4 + 'destination unreachable'. It has been suggested that they could + also run a dummy 6to4 relay at that address which always returns + ICMPv6 'destination unreachable' as a 6to4 packet. However, these + techniques are not very effective, since most current end-user 6to4 + implementations will ignore them. + + If an operator is providing legitimate global addresses to customers + (neither RFC 1918 nor bogon addresses), and also running Carrier + Grade NAT (Large Scale NAT) between this address space and the global + address space of the Internet, then 6to4 cannot work properly. Such + an operator should also take care to return 'destination unreachable' + for 6to4 traffic. Alternatively, they could offer untranslated + address space to the customers concerned. + +4.2.4. DNS Issues + + A customer who is intentionally using 6to4 may also need to create + AAAA records, and the operator should be able to support this, even + if the DNS service itself runs exclusively over IPv4. However, + customers should be advised to consider carefully whether their 6to4 + service is sufficiently reliable for this. + + Operators could, in principle, offer reverse DNS support for 6to4 + users [RFC5158], although this is not straightforward for domestic + customers. + +4.2.5. Rogue Router Advertisements + + Paradoxically, operators in this category should consider whether + they need to defend themselves against rogue IPv6 RA messages + [RFC6105], since such messages may appear from devices seeking to + + + +Carpenter Informational [Page 12] + +RFC 6343 6to4 Advisory August 2011 + + + operate as 6to4 routers and confuse any user devices with IPv6 + enabled by default. Eventually, the measures being designed by the + IETF Source Address Validation Improvement (SAVI) working group will + assist with this problem. In the short term, IPv4-only operators may + choose to filter out packets with the IPv6 Ethertype (0x86DD) in + their access equipment; this will definitively remove rogue RA + packets. + +4.2.6. Planning for IPv6 Deployment + + Enterprise operators who have complete administrative control of all + end systems may choose to disable 6to4 in those systems as an + integral part of their plan to deploy IPv6. + + Some IPv4 operators have chosen to install a 6to4 relay, connected + via an IPv6-in-IPv4 tunnel to an IPv6 operator, as a first step + before native IPv6 deployment. The routing guidelines in Section 4.4 + would apply. However, offering genuine IPv6 service to interested + customers, even if tunneled, would generally be a better first step. + +4.3. Consumer ISPs, and Enterprise Networks, That Do Support IPv6 + + Once an operator does support IPv6 service, whether experimentally or + in production, it is almost certain that users will get better + results using this service than by continuing to use 6to4. + Therefore, these operators are encouraged to advise their users to + disable 6to4 and they should not create DNS records for any 6to4 + addresses. + + Such an operator may automatically fall into one of the following two + categories (transit provider or content provider), so the guidelines + in Sections 4.4 or 4.5 will apply instead. + + Operators in this category should make sure that no routers are + unintentionally or by default set up as active 6to4 relays. + Unmanaged 6to4 relays will be a source of problems. + + Operators in this category should consider whether they need to + defend themselves against rogue RA messages with an RA Guard solution + [RFC6105]. If RA Guard is not available, it may help in some cases + if at least one legitimate IPv6 router per LAN supports [RFC4191] and + sets the Router Advertisement router preference bits to 01 (high + preference). Eventually, the measures being designed by the IETF + Source Address Validation Improvement (SAVI) working group will + assist with this problem. + + + + + + +Carpenter Informational [Page 13] + +RFC 6343 6to4 Advisory August 2011 + + +4.4. Transit ISPs and Internet Exchange Points + + We assume that transit ISPs have IPv6 connectivity. To reduce the + negative impact of Anycast 6to4 on all their client networks, it is + strongly recommended that they each run an Anycast 6to4 relay + service. This will have the additional advantage that they will + terminate the 6to4 IPv4 packets and can then forward the decapsulated + IPv6 traffic according to their own policy. Otherwise, they will + blindly forward all the encapsulated IPv6 traffic to a competitor who + does run a relay. + + Although most modern Internet Exchange Points do not offer IP layer + services, an Internet exchange point (IXP) could choose to operate an + Anycast 6to4 relay service for the benefit of its customers. If so, + it should follow the recommendations in this section. + + It is of critical importance that routing to this service is + carefully managed: + + 1. The IPv4 prefix 192.88.99.0/24 must be announced only towards + client IPv4 networks whose outbound 6to4 packets will be + accepted. + + 2. The IPv6 prefix 2002::/16 must be announced towards native IPv6. + The relay must accept all traffic towards 2002::/16 that reaches + it, so the scope reached by this announcement should be carefully + planned. It must reach all client IPv6 networks of the transit + ISP. If it reaches a wider scope, the relay will be offering a + free ride to non-clients. + + 3. As discussed in item 2 of Section 3, the choice of IPv4 source + address used when the relay sends 6to4 packets back towards a + 6to4 user is important. The best choice is likely to be + 192.88.99.1, not the relay's unicast IPv4 address, unless ingress + filtering is an issue. This is to avoid failure if the user is + behind a stateful firewall. + + 4. The relay should be capable of responding correctly to ICMPv6 + echo requests encapsulated in IPv4 protocol 41, typically with + outer destination address 192.88.99.1 and inner destination + address 2002:c058:6301::. (As noted previously, some 6to4 hosts + are known to send echo requests with Hop Limit = 1, which allows + them to rapidly detect the presence or absence of a relay in any + case, but operators cannot rely on this behavior.) + + 5. Protocol 41 must not be filtered in any IPv4 network or + firewalls. + + + + +Carpenter Informational [Page 14] + +RFC 6343 6to4 Advisory August 2011 + + + 6. As a matter of general practice, which is essential for 6to4 to + work well, IPv6 PMTUD must be possible, which means that ICMPv6 + must not be blocked anywhere [RFC4890]. This also requires that + the relay has a sufficiently high ICMP error generation + threshold. For a busy relay, a typical default rate limit of 100 + packets per second is too slow. On a busy relay, 1000 pps or + more might be needed. If ICMPv6 "Packet Too Big" error messages + are rate limited, users will experience PMTUD failure. + + 7. The relay must have adequate performance, and since load + prediction is extremely hard, it must be possible to scale it up + or, perhaps better, to replicate it as needed. Since the relay + process is stateless, any reasonable method of load sharing + between multiple relays will do. + + 8. Of course, the relay must be connected directly to global IPv4 + space, with no NAT. + + Operators in this category should make sure that no routers are + unintentionally or by default set up as active 6to4 relays. + Unmanaged 6to4 relays will be a source of problems. + +4.5. Content Providers and Their ISPs + + We assume that content providers and their ISPs have IPv6 + connectivity, and that the servers are dual stacked. The following + applies to content servers as such, but equally to web hosting + servers, servers that form part of a content distribution network, + load balancers in front of a server farm, and HTTP caches. There is + a need to avoid the situation where a client host, configured with + Anycast 6to4, succeeds in sending an IPv6 packet to the server, but + the 6to4 return path fails as described above. To avoid this, there + must be a locally positioned 6to4 relay. Large content providers are + advised to operate their own relays, and ISPs should do so in any + case. There must be a 2002::/16 route from the content server to the + relay. As noted in the previous section, the corresponding route + advertisement must be carefully scoped, since any traffic that + arrives for 2002::/16 must be relayed. + + Such a relay may be dedicated entirely to return traffic, in which + case, it need not respond to the 6to4 anycast address. + + Nevertheless, it seems wisest to ensure that when the relay sends + 6to4 packets back towards a 6to4 user, they should have 192.88.99.1 + as their IPv4 source address (not the relay's unicast IPv4 address). + As noted above, this is to avoid problems if the user is behind a + stateful firewall that drops UDP packets from addresses that have not + + + + +Carpenter Informational [Page 15] + +RFC 6343 6to4 Advisory August 2011 + + + been seen in outbound traffic. However, it is also necessary that + 192.88.99.1 is not blocked by upstream ingress filtering -- this + needs to be tested. + + Without careful engineering, there is nothing to make the return path + as short as possible. It is highly desirable to arrange the scope of + advertisements for 2002::/16 such that content providers have a short + path to the relay, and the relay should have a short path to the ISP + border. Care should be taken about shooting off advertisements for + 2002::/16 into BGP4; they will become traffic magnets. If every ISP + with content provider customers operates a relay, there will be no + need for any of them to be advertised beyond each ISP's own + customers. + + Protocol 41 must not be filtered in the ISP's IPv4 network or + firewalls. If the relays are placed outside the content provider's + firewall, the latter may filter protocol 41 if desired. + + The relay must have adequate performance, and since load prediction + is extremely hard, it must be possible to scale it up or, perhaps + better, to replicate it as needed. Since the relay process is + stateless, any reasonable method of load sharing between multiple + relays will do. + + The relay must of course be connected directly to global IPv4 space, + with no NAT. + + An option is to embed the relay function directly in the content + server or first hop router. This is straightforward, since it can be + achieved by enabling a local 6to4 interface, and using it to route + 2002::/16 for outbound packets. (This might not allow use of + 192.88.99.1 as the source address.) Further details are to be found + at [Huston-b]. However, in this case protocol 41 must be allowed by + the firewalls. + + Content providers who do embed the relay function in this way could, + in theory, accept inbound 6to4 traffic as well. This is highly + unadvisable since, according to the rules of 6to4, they would then + have to relay traffic for other IPv6 destinations, too. So they + should not be reachable via 192.88.99.1. Also, they should certainly + not create an AAAA record for their 6to4 address -- their inbound + IPv6 access should be native, and advertising a 6to4 address might + well lead to unicast reverse path forwarding (uRPF) [RFC3704] ingress + filtering problems. + + To avoid the path MTU problem described above, content servers should + also set their IPv6 MTU to a safe value. From experience, 1280 bytes + (the minimum allowed for IPv6) is recommended; again, see [Huston-b]. + + + +Carpenter Informational [Page 16] + +RFC 6343 6to4 Advisory August 2011 + + + Of course, ICMPv6 "Packet Too Big" must not be blocked or rate- + limited anywhere [RFC4890]. + + Reverse DNS delegations are highly unlikely to exist for 6to4 + clients, and are by no means universal for other IPv6 clients. + Content providers (and, in fact, all service providers) should not + rely on them as a pseudo-security check for IPv6 clients. + + Operators and content providers should make sure that no routers are + unintentionally or by default set up as active 6to4 relays. + Unmanaged 6to4 relays will be a source of problems. + +5. Tunnels Managed by ISPs + + There are various ways, such as tunnel brokers [RFC3053], 6rd + [RFC5969], and Layer 2 Tunneling Protocol version 2 (L2TPv2) hub-and- + spoke [RFC5571], by which Internet Service Providers can provide + tunneled IPv6 service to subscribers in a managed way, in which the + subscriber will acquire an IPv6 prefix under a normal provider-based + global IPv6 prefix. Most of the issues described for 6to4 do not + arise in these scenarios. However, for IPv6-in-IPv4 tunnels used by + clients behind a firewall, it is essential that IPv4 protocol 41 is + not blocked. + + As a matter of general practice, IPv6 PMTUD must be possible, which + means that ICMPv6 "Packet Too Big" must not be blocked or rate- + limited anywhere [RFC4890]. + +6. Security Considerations + + There is a general discussion of security issues for IPv6-in-IPv4 + tunnels in [RFC6169], and [TUNNEL-LOOPS] discusses possible malicious + loops. [RFC3964] specifically discusses 6to4 security. In summary, + tunnels create a challenge for many common security mechanisms, + simply because a potentially suspect packet is encapsulated inside a + harmless outer packet. All these considerations apply to the + automatic mechanisms discussed in this document. However, it should + be noted that if an operator provides well-managed servers and relays + for 6to4, non-encapsulated IPv6 packets will pass through well- + defined points (the native IPv6 interfaces of those servers and + relays) at which security mechanisms may be applied. + + A blanket recommendation to block protocol 41 is not compatible with + mitigating the 6to4 problems described in this document. + + + + + + + +Carpenter Informational [Page 17] + +RFC 6343 6to4 Advisory August 2011 + + +7. Acknowledgements + + Useful comments and contributions were made by Emile Aben, Mikael + Abrahamsson, Tore Anderson, Hermin Anggawijaya, Jack Bates, Cameron + Byrne, Tim Chown, Remi Despres, Jason Fesler, Wes George, Philip + Homburg, Ray Hunter, Geoff Huston, Eric Kline, Victor Kuarsingh, + Martin Levy, David Malone, Alexey Melnikov, Martin Millnert, Keith + Moore, Gabi Nakibly, Michael Newbery, Phil Pennock, Pekka Savola, + Mark Smith, Nathan Ward, James Woodyatt, and others. + +8. References + +8.1. Normative References + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 + Domains via IPv4 Clouds", RFC 3056, February 2001. + + [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay + Routers", RFC 3068, June 2001. + +8.2. Informative References + + [Aben] Aben, E., "6to4 - How Bad is it Really?", 2010, <ht + tps://labs.ripe.net/Members/emileaben/ + 6to4-how-bad-is-it-really>. + + [Anderson] Anderson, T., "IPv6 dual-stack client loss in + Norway", 2010, <http://www.fud.no/ipv6/>. + + [CGN] Perreault, S., Yamagata, I., Miyakawa, S., + Nakagawa, A., and H. Ashida, "Common requirements + for Carrier Grade NAT (CGN)", Work in Progress, + July 2011. + + [DNSWHITE] Livingood, J., "IPv6 AAAA DNS Whitelisting + Implications", Work in Progress, June 2011. + + [EYEBALLS-IPV6] Wing, D. and A. Yourtchenko, "Happy Eyeballs: + Trending Towards Success with Dual-Stack Hosts", + Work in Progress, October 2010. + + [HISTORIC] Troan, O., "Request to move Connection of IPv6 + Domains via IPv4 Clouds (6to4) to Historic status", + Work in Progress, June 2011. + + [Huston-a] Huston, G., "Flailing IPv6", 2010, <http:// + www.potaroo.net/ispcol/2010-12/6to4fail.html>. + + + + +Carpenter Informational [Page 18] + +RFC 6343 6to4 Advisory August 2011 + + + [Huston-b] Huston, G., "Two Simple Hints for Dual Stack + Servers", 2010, <http://www.potaroo.net/ispcol/ + 2010-05/v6hints.html>. + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, + G., and E. Lear, "Address Allocation for Private + Internets", BCP 5, RFC 1918, February 1996. + + [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", + RFC 2923, September 2000. + + [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, + "IPv6 Tunnel Broker", RFC 3053, January 2001. + + [RFC3484-REVISE] Matsumoto, A., Kato, J., Fujisaki, T., and T. + Chown, "Update to RFC 3484 Default Address + Selection for IPv6", Work in Progress, July 2011. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for + Multihomed Networks", BCP 84, RFC 3704, March 2004. + + [RFC3964] Savola, P. and C. Patel, "Security Considerations + for 6to4", RFC 3964, December 2004. + + [RFC4191] Draves, R. and D. Thaler, "Default Router + Preferences and More-Specific Routes", RFC 4191, + November 2005. + + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. + + [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for + Filtering ICMPv6 Messages in Firewalls", RFC 4890, + May 2007. + + [RFC5158] Huston, G., "6to4 Reverse DNS Delegation + Specification", RFC 5158, March 2008. + + [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, + B., Toutain, L., and J. Tremblay, "Softwire Hub and + Spoke Deployment Framework with Layer Two Tunneling + Protocol Version 2 (L2TPv2)", RFC 5571, June 2009. + + [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment + on IPv4 Infrastructures (6rd) -- Protocol + Specification", RFC 5969, August 2010. + + + + +Carpenter Informational [Page 19] + +RFC 6343 6to4 Advisory August 2011 + + + [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router + Advertisement Problem Statement", RFC 6104, + February 2011. + + [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., + and J. Mohacsi, "IPv6 Router Advertisement Guard", + RFC 6105, February 2011. + + [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, + "Security Concerns with IP Tunneling", RFC 6169, + April 2011. + + [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and + P. Roberts, "Issues with IP Address Sharing", + RFC 6269, June 2011. + + [Savola] Savola, P., "Observations of IPv6 Traffic on a 6to4 + Relay", ACM SIGCOMM CCR 35 (1) 23-28, 2006. + + [TUNNEL-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack + using IPv6 Automatic Tunnels: Problem Statement and + Proposed Mitigations", Work in Progress, May 2011. + +Author's Address + + Brian Carpenter + Department of Computer Science + University of Auckland + PB 92019 + Auckland, 1142 + New Zealand + + EMail: brian.e.carpenter@gmail.com + + + + + + + + + + + + + + + + + + +Carpenter Informational [Page 20] + |