idnits 2.17.1 draft-ietf-v6ops-6to4-advisory-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 22, 2011) is 4690 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) == Outdated reference: A later version (-05) exists of draft-ietf-6man-rfc3484-revise-03 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-01 == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-6to4-to-historic-04 == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational June 22, 2011 5 Expires: December 24, 2011 7 Advisory Guidelines for 6to4 Deployment 8 draft-ietf-v6ops-6to4-advisory-02 10 Abstract 12 This document provides advice to network operators about deployment 13 of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It 14 is principally addressed to Internet Service Providers, including 15 those that do not yet support IPv6, and to Content Providers. Some 16 advice to implementers is also included. The intention of the advice 17 is to minimise both user dissatisfaction and help desk calls. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 24, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Principles of Operation . . . . . . . . . . . . . . . . . . . 4 55 2.1. Router 6to4 . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Anycast 6to4 . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Problems Observed . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Advisory Guidelines . . . . . . . . . . . . . . . . . . . . . 10 59 4.1. Vendor Issues . . . . . . . . . . . . . . . . . . . . . . 10 60 4.2. Consumer ISPs, and enterprise networks, that do not 61 support IPv6 in any way . . . . . . . . . . . . . . . . . 11 62 4.2.1. Anycast address availability . . . . . . . . . . . . . 11 63 4.2.2. Protocol 41 . . . . . . . . . . . . . . . . . . . . . 11 64 4.2.3. IPv4 prefix issues . . . . . . . . . . . . . . . . . . 12 65 4.2.4. DNS issues . . . . . . . . . . . . . . . . . . . . . . 12 66 4.2.5. Rogue Router Advertisements . . . . . . . . . . . . . 12 67 4.2.6. Planning for IPv6 deployment . . . . . . . . . . . . . 13 68 4.3. Consumer ISPs, and enterprise networks, that do 69 support IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.4. Transit ISPs and Internet Exchange Points . . . . . . . . 13 71 4.5. Content providers and their ISPs . . . . . . . . . . . . . 15 72 5. Tunnels Managed by ISPs . . . . . . . . . . . . . . . . . . . 17 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 76 9. Change log [RFC Editor: please remove] . . . . . . . . . . . . 18 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 1. Introduction 84 A technique for automatic tunneling of IPv6 over IPv4, intended for 85 situations where a user may wish to access IPv6-based services via a 86 network that does not support IPv6, was defined a number of years 87 ago. It is known as 6to4 [RFC3056] [RFC3068] and is quite widely 88 deployed in end systems, especially desktop and laptop computers. 89 Also, 6to4 is supported in a number of popular models of CPE routers, 90 some of which have it enabled by default, leading to quite widespread 91 unintentional deployment by end users. 93 Unfortunately, experience shows that the method has some problems in 94 current deployments that can lead to connectivity failures. These 95 failures either cause long retry delays or complete failures for 96 users trying to connect to services. In many cases, the user may be 97 quite unaware that 6to4 is in use, and when the user contacts a help 98 desk, in all probability the help desk is unable to correctly 99 diagnose the problem. Anecdotally, many help desks simply advise 100 users to disable IPv6, thus defeating the whole purpose of the 101 mechanism, which was to encourage early adoption of IPv6. 103 The main goal of the present document is to offer advice to network 104 operators on how to deal with this situation more constructively than 105 by disabling 6to4. It briefly describes the principle of operation, 106 then describes the problems observed, and finally offers specific 107 advice on the available methods of avoiding the problems. Note that 108 some of this advice applies to ISPs that do not yet support IPv6, 109 since their customers and help desks are significantly affected in 110 any case. 112 Other advice applies to content providers and implementers, but this 113 document does not discuss aspects that are mainly outside the scope 114 of network operators: 115 1. Operating system preferences between IPv4 and IPv6 when both 116 appear to be available [I-D.ietf-6man-rfc3484-revise]. 117 2. Ensuring that application software deals gracefully with 118 connectivity problems [I-D.wing-v6ops-happy-eyeballs-ipv6]. 119 3. Some content providers have chosen to avoid the problem by hiding 120 their IPv6 address except from customers of pre-qualified 121 networks [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]. 123 A companion document [I-D.ietf-v6ops-6to4-to-historic] proposes to 124 reclassify 6to4 as Historic. However, this will not remove the 125 millions of existing hosts and customer premises equipments that 126 implement 6to4. Hence, the advice in this document remains 127 necessary. 129 2. Principles of Operation 131 There are two variants of 6to4 which are referred to here as "Router 132 6to4" and "Anycast 6to4". To understand Anycast 6to4, it is 133 necessary first to understand Router 6to4. 135 2.1. Router 6to4 137 Router 6to4 is the original version, documented in [RFC3056]. The 138 model assumes that a user site operates native IPv6, but that its ISP 139 provides no IPv6 service. The site border router acts as a 6to4 140 router. If its external global 32-bit IPv4 address is V4ADDR, the 141 site automatically inherits the IPv6 prefix 2002:V4ADDR::/48. (The 142 explanation in RFC 3056 is somewhat confusing, as it refers to the 143 obsolete "Top Level Aggregator" terminology.) The prefix 2002: 144 V4ADDR::/48 will be used and delegated for IPv6 service within the 145 user site. 147 Consider two such site border routers, with global IPv4 addresses 148 192.0.2.170 and 192.0.2.187, and therefore inheriting the IPv6 149 prefixes 2002:c000:2aa::/48 and 2002:c000:2bb::/48 respectively. The 150 routers can exchange IPv6 packets by encapsulating them in IPv4 using 151 protocol number 41, and sending them to each other at their 152 respective IPv4 addresses. In fact, any number of 6to4 routers 153 connected to the IPv4 network can directly exchange IPv6 packets in 154 this way. 156 Some 6to4 routers are also configured as "Relay routers." They 157 behave as just described, but in addition they obtain native IPv6 158 connectivity with a normal IPv6 prefix. They announce an IPv6 route 159 to 2002::/16. For example, assume that the 6to4 router at 160 192.0.2.187 is a relay router, whose address on the 6to4 side is 161 2002:c000:2bb::1. Suppose that a host with the 6to4 address 2002: 162 c000:2aa::123 sends an IPv6 packet to a native IPv6 destination such 163 as 2001:db8:123:456::321. Assume that the 6to4 router at 192.0.2.170 164 has its IPv6 default route set to 2002:c000:2bb::1, i.e. the relay. 165 The packet will be delivered to the relay, encapsulated in IPv4. The 166 relay will decapsulate the packet and forward it into native IPv6 for 167 delivery. When the remote host replies, the packet (source 2001:db8: 168 123:456::321, destination 2002:c000:2aa::123) will find a route to 169 2002::/16 and hence be delivered to a 6to4 relay. The process will 170 be reversed and the packet will be encapsulated and forwarded to the 171 6to4 router at 192.0.2.170 for final delivery. 173 Note that this process does not require the same relay to be used in 174 both directions. The outbound packet will go to whichever relay is 175 configured as the default IPv6 router at the source router, and the 176 return packet will go to whichever relay is announcing a route to 177 2002::/16 in the vicinity of the remote IPv6 host. 179 There are of course many further details in RFC 3056, most of which 180 are irrelevant to current operational problems. 182 2.2. Anycast 6to4 184 Router 6to4 assumes that 6to4 routers and relays will be managed and 185 configured cooperatively. In particular, 6to4 sites need to 186 configure a relay router willing to carry their outbound traffic, 187 which becomes their default IPv6 router (except for 2002::/16). The 188 objective of the anycast variant, defined in [RFC3068], is to avoid 189 any need for such configuration. The intention was to make the 190 solution available for small or domestic users, even those with a 191 single host or simple home gateway rather than a border router. This 192 is achieved quite simply, by defining 192.88.99.1 as the default IPv4 193 address for a 6to4 relay, and therefore 2002:c058:6301:: as the 194 default IPv6 router address for a 6to4 site. 196 Since Anycast 6to4 implies a default configuration for the user site, 197 it does not require any particular user action. It does require an 198 IPv4 anycast route to be in place to a relay at 192.88.99.1. As with 199 Router 6to4, there is no requirement that the return path goes 200 through the same relay. 202 3. Problems Observed 204 It should be noted that Router 6to4 was not designed to be an 205 unmanaged solution. Quite the contrary: RFC 3056 contains a number 206 of operational recommendations intended to avoid routing issues. In 207 practice, there are few if any deployments of Router 6to4 following 208 these recommendations. Mostly, Anycast 6to4 has been deployed. In 209 this case, the user site (either a single host or a small broadband 210 gateway) discovers that it doesn't have native IPv6 connectivity, but 211 that it does have a global IPv4 address and can resolve AAAA queries, 212 and therefore assumes that it can send 6to4 packets to 192.88.99.1. 214 Empirically, 6to4 appears to suffer from a significant level of 215 connection failure; see [Aben] and [Huston-a]. In experiments 216 conducted on a number of dual stack web servers, the TCP connection 217 failure rate has been measured. In these experiments, the client's 218 connection attempt to a server was considered to have failed when the 219 server received a TCP SYN packet and sent a SYN/ACK packet in 220 response, but received no ACK packet to complete the initial TCP 221 3-way handshake. The experiment conducted by Aben recorded a failure 222 rate of between 9% and 20% of all 6to4 connection attempts. The 223 experiment conducted by Huston has recorded a failure rate of between 224 9% and 19% of all 6to4 clients. In this latter experiment it was 225 further noted that between 65% to 80% of all 6to4 clients who failed 226 to connect using 6to4 were able to make a successful connection using 227 IPv4, while the remainder did not make any form of IPv4 connection 228 attempt, successful or otherwise, using the mapped IPv4 address as a 229 source address. No connection attempts using embedded RFC 1918 IPv4 230 addresses were recorded by the server. 232 There have been several possible reasons offered for this form of 233 6to4 connection failure. One is the use of private IPv4 addresses 234 embedded in the 6to4 address, making the return path for the 6to4 235 tunnel infeasible, and the second is the use of local filters and 236 firewalls that drop incoming IP packets that use IP protocol 41. If 237 the former case were prevalent it would be reasonable to expect that 238 a significant proportion of failed 6to4 connections would use 239 embedded IPv4 addresses that are either drawn from the private use 240 (RFC 1918) address ranges, contrary to RFC 3056, or from addresses 241 that are not announced in the Internet's IPv4 inter-domain routing 242 table. Neither case was observed to any significant volume in the 243 experiments conducted by Huston. Furthermore, the experimental 244 conditions were varied to use a return 6to4 tunnel with either the 245 native IPv4 source address of the dual stack server or an IPv4 source 246 address of 192.88.99.1. No change in the 6to4 connection failure 247 rate was observed between these two configurations; however, other 248 operators have reported significant problems when replying from the 249 native address, caused by stateful firewalls at the user site. Given 250 that the server used its own 6to4 relay for the return path, the only 251 difference in the IP packet itself between the successful IPv4 252 connections and the failed 6to4 connections was the IP protocol 253 number, which was 6 (TCP) for the successful IPv4 connections and 41 254 (IPv6 payload) for the failed 6to4 connections. The inference from 255 these experiments is that one likely reason for the high connection 256 failure rate for 6to4 connections is the use of local filters close 257 to the end-user that block incoming packets with protocol 41, in some 258 cases made worse by stateful firewalls if the source address is not 259 192.88.99.1. 261 In a dual stack context this connection failure rate was effectively 262 masked by the ability of the client system to recover from the 263 failure and make a successful connection using IPv4. In this case 264 the only effect on the client system was a delay in making the 265 connection of between 7 and 20 seconds as the client's system timed 266 out on the 6to4 connection attempts (see 267 [I-D.wing-v6ops-happy-eyeballs-ipv6]). 269 This experience and further analysis shows that specific operational 270 problems with Anycast 6to4 include: 272 1. Outbound Black Hole: 192.88.99.1 does not generate 'destination 273 unreachable' but in fact packets sent to that address are 274 dropped. This can happen due to routing or firewall 275 configuration, or even because the relay that the packets happen 276 to reach contains an ACL such that they are discarded. 278 This class of problem arises because the user's ISP is accepting 279 a route to 192.88.99.0/24 despite the fact that it doesn't go 280 anywhere useful. Either the user site or its ISP is dropping 281 outbound Protocol 41 traffic, or the upstream operator is 282 unwilling to accept incoming 6to4 packets from the user's ISP. 283 The latter is superficially compatible with the design of Router 284 6to4 (referred to as "unwilling to relay" in RFC 3056). However, 285 the simple fact of announcing a route to 192.88.99.0/24 in IPv4, 286 coupled with the behavior described in RFC 3068, amounts to 287 announcing a default route for IPv6 to all 6to4 sites that 288 receive the IPv4 route. This violates the assumptions of RFC 289 3056. 291 The effect of this problem on users is that their IPv6 stack 292 believes that it has 6to4 connectivity, but in fact all outgoing 293 IPv6 packets are black-holed. The prevalence of this problem is 294 hard to measure, since the resulting IPv6 packets can never be 295 observed from the outside. 296 2. Inbound Black Hole: In this case, 6to4 packets sent to 297 192.88.99.1 are correctly delivered to a 6to4 relay, and reply 298 packets are returned, but they are dropped by an inbound Protocol 299 41 filter. As far as the user is concerned, the effect is the 300 same as the previous case: IPv6 is a black hole. Many enterprise 301 networks are believed to be set up in this way. Connection 302 attempts due to this case can be observed by IPv6 server 303 operators, in the form of SYN packets from addresses in 2002::/16 304 followed by no response to the resulting SYN/ACK. From the 305 experiments cited above, this appears to be a significant problem 306 in practice. 308 This problem is complicated by three variables: the firewall 309 applying the Protocol 41 filter may be stateless or stateful; the 310 relay may source its packets from its native IPv4 address or from 311 192.88.99.1; packets from the relay may be subject to IPv4 312 ingress filtering. If the Protocol 41 filter is stateless, 6to4 313 will never succeed. If it is stateful, the firewall will drop 314 inbound packets from addresses that have not been seen in 315 outbound traffic on the same port. In this case, 6to4 will only 316 succeed if the packets are sourced from 192.88.99.1. But if the 317 relay is subject to ingress filtering, only packets from its 318 native IPv4 address can be transmitted. There are therefore only 319 three combinations that can succeed: 321 1. No Protocol 41 filter, with the relay using its native IPv4 322 source address. 323 2. No Protocol 41 filter, with the relay using the anycast IPv4 324 source address and with no ingress filter. 325 3. A stateful Protocol 41 firewall, with the relay using the 326 anycast IPv4 source address and with no ingress filter. 327 3. No Return Relay: If the Outbound Black Hole problem does not 328 occur, i.e. the outgoing packet does reach the intended native 329 IPv6 destination, the target system will send a reply packet, to 330 2002:c000:2aa::123 in our example above. Then 2002::/16 may or 331 may not be successfully routed. If it is not routed, the packet 332 will be dropped (hopefully with 'destination unreachable'). 333 According to RFC 3056, an unwilling relay "MUST NOT advertise any 334 2002:: routing prefix into the native IPv6 domain"; therefore, 335 conversely, if this prefix is advertised the relay must relay 336 packets regardless of source and destination. However, in 337 practice the problem arises that some relays reject packets that 338 they should relay, based on their IPv6 source address. 340 Whether the native IPv6 destination has no route to 2002::/16, or 341 it turns out to have a route to an unwilling relay, the effect is 342 the same: all return IPv6 packets are black-holed. While there 343 is no direct evidence of the prevalence of this problem, it 344 certainly exists in practice. 345 4. Large RTT: In the event that none of the above three problems 346 applies, and a two-way path does in fact exist between a 6to4 347 host and a native host, the round trip time may be quite large 348 and variable since the paths to the two relays are unmanaged and 349 may be complex. Overloaded relays might also cause highly 350 variable RTT. 351 5. PMTUD Failure: A common link MTU size observed on the Internet 352 today is 1500 bytes. However, when using 6to4 the path MTU is 353 less than this due to the encapsulation header. Thus a 6to4 354 client will normally see a link MTU that is less than 1500, but a 355 native IPv6 server will see 1500. It has been observed that Path 356 MTU Discovery does not always work, and this can lead to 357 connectivity failures. Even if a TCP SYN/ACK exchange works, TCP 358 packets with full size payloads may simply be lost. This problem 359 is apparently exacerbated in some cases by failure of the TCP MSS 360 negotiation mechanism [RFC2923]. These failures are 361 disconcerting even to an informed user, since a standard 'ping' 362 from the client to the server will succeed, because it generates 363 small packets, and the successful SYN/ACK exchange can be traced. 364 Also, the failure may occur on some paths but not others, so a 365 user may be able to fetch web pages from one site, but only ping 366 another. 368 Additionally, there is a problem if 6to4 is enabled on a router 369 and it advertises the resulting prefix on a LAN, but does not 370 also advertise a smaller MTU; in this case TCP MSS negotiation 371 will definitely fail. 372 6. Reverse DNS Failure: Typically a 6to4-addressed host will not 373 have a reverse DNS delegation. If reverse DNS is used as a 374 pseudo-security check, it will fail. 375 7. Bogus Address Failure: By design, 6to4 does not work and will not 376 activate itself if the available V4ADDR is a private address 377 [RFC1918]. However it will also not work if the available V4ADDR 378 is a "bogon", i.e. a global address that is being used by the 379 operator as a private address. A common case of this is a legacy 380 wireless network using 1.1.1.0/24 as if it was a private address. 381 In this case, 6to4 will assume it is connected to the global 382 Internet, but there is certainly no working return path. 384 This failure mode will also occur if an ISP is operating a 385 Carrier Grade NAT [I-D.ietf-behave-lsn-requirements] between its 386 customers and the Internet, and is using global public address 387 space as if it were private space to do so. 388 8. Faulty 6to4 Implementations: It has been reported that some 6to4 389 implementations attempt to activate themselves even when the 390 available IPv4 address is an RFC 1918 address. This is in direct 391 contradiction to RFC 3056, and will produce exactly the same 392 failure mode as Bogus Address Failure. It is of course outside 393 the ISP's control. 394 9. Difficult Fault Diagnosis: The existence of all the above failure 395 modes creates a problem of its own: very difficult fault 396 diagnosis, especially if the only symptom reported by a user is 397 slow access to web pages, caused by a long timeout before 398 fallback to IPv4. Tracking down anycast routing problems and 399 PMTUD failures is particularly hard. 401 The practical impact of the above problems, which are by no means 402 universal as there is considerable successful use of Anycast 6to4, 403 has been measured at a fraction of 1% loss of attempted connections 404 to dual-stack content servers [Anderson]. This is because a small 405 fraction of client hosts attempt to connect using 6to4, and up to 20% 406 of these experience one of the above failure modes. While this seems 407 low, it amounts to a significant financial impact for content 408 providers. Also, end users frustrated by the poor response times 409 caused by fall-back to IPv4 connectivity 410 [I-D.wing-v6ops-happy-eyeballs-ipv6] are considered likely to 411 generate help desk calls with their attendant costs. 413 A rather different operational problem caused incidentally by 6to4 is 414 that, according to observations made at the University of Southampton 415 by Tim Chown and James Morse, and at other sites, rogue Router 416 Advertisements [RFC6104] often convey a 2002::/16 prefix. This 417 appears to be due to misbehaviour by devices acting as local IPv6 418 routers or connection-sharing devices but issuing RA messages on the 419 wrong interface. Such a device, if it obtains IPv6 connectivity via 420 an upstream link to the Internet, should only issue the corresponding 421 RA messages on its downstream link to the nodes intended to share its 422 Internet connection. Issuing RA messages on the upstream link will 423 perturb any other IPv6 hosts on that link. If 6to4 routing is 424 enabled by default on a device that exhibits this faulty behaviour, 425 the resulting rogue RA messages will indeed convey a 2002::/16 426 prefix. 428 4. Advisory Guidelines 430 There are several types of operator involved, willingly or 431 unwillingly, in the Anycast 6to4 scenario and they will all suffer if 432 things work badly. To avoid operational problems and customer 433 dissatisfaction, there is a clear incentive for each of them to take 434 appropriate action, as described below. 436 This document avoids formal normative language, because it is highly 437 unlikely that the guidelines apply universally. Each operator will 438 make its own decisions about which of the following guidelines are 439 useful in its specific scenario. 441 4.1. Vendor Issues 443 Although this document is aimed principally at operators, there are 444 some steps that implementers and vendors of 6to4 should take. 445 1. Some vendors of routers, including customer premises equipment, 446 have not only included support for 6to4 in their products, but 447 have enabled it by default. This is bad practice - it should 448 always be a conscious decision by a user to enable 6to4. Many of 449 the above problems only occur due to unintentional deployment of 450 6to4. 451 2. Similarly, host operating systems should not enable Anycast 6to4 452 by default; it should always be left to the user to switch it on. 453 3. Any 6to4 implementation that attempts to activate itself when the 454 available IPv4 address is an RFC 1918 address is faulty and needs 455 to be updated. 456 4. 6to4 implementations should adopt updated IETF recommendations on 457 address selection [I-D.ietf-6man-rfc3484-revise]. 458 5. 6to4 relay implementations must carefully follow section 3.2 of 459 [RFC4213] to ensure correct handling of MTU issues. 460 6. 6to4 router or connection-sharing implementations must avoid 461 issuing rogue RAs [RFC6104]. Additionally, where 6to4 is being 462 enabled by a node for Internet connection sharing purposes, and 463 the node supports [RFC4191], then it should set the Router 464 Advertisement router preference bits to 11 (low preference). 466 4.2. Consumer ISPs, and enterprise networks, that do not support IPv6 467 in any way 469 4.2.1. Anycast address availability 471 To reduce the negative impact of Anycast 6to4 deployed (probably 472 unknowingly) by users, and consequent user dissatisfaction and help 473 desk calls, such ISPs should check in sequence: 474 1. Does the ISP have a route to 192.88.99.1? (This means an 475 explicit route, or knowledge that the default upstream provider 476 has an explicit route. A default route doesn't count!) 477 2. If so, is it functional and stable? 478 3. If so, is the ping time reasonably short? 479 4. If so, does the relay willingly accept 6to4 traffic from the 480 ISP's IPv4 prefixes? (Note that this is an administrative as 481 well as a technical question - is the relay's operator willing to 482 accept the traffic?) 484 Unless the answer to all these questions is 'yes', the operator 485 should consider blocking the route to 192.88.99.1 and generating an 486 IPv4 'destination unreachable' message. This may cause some 6to4 487 implementations to fall back to IPv4 more quickly. There is little 488 operational experience with this, however. 490 Some implementations also perform some form of 6to4 relay 491 qualification. For example, one host implementation (Windows) tests 492 the Protocol 41 reachability by sending an ICMPv6 echo request with 493 Hop Limit=1 to the relay, expecting a response or Hop Limit exceeded 494 error back. Lack of any response indicates that the 6to4 relay does 495 not work so 6to4 is turned off [Savola]. 497 A more constructive approach for such an ISP is to seek out a transit 498 provider who is indeed willing to offer outbound 6to4 relay service, 499 so that the answer to each of the questions above is positive. 501 4.2.2. Protocol 41 503 ISPs in this class should always allow protocol 41 through their 504 network and firewalls. Not only is this a necessary condition for 505 6to4 to work, but it also allows users who want to use a configured 506 IPv6 tunnel service to do so. 508 Some operators, particularly enterprise networks, silently block 509 Protocol 41 on security grounds. Doing this on its own is bad 510 practice, since it contributes to the problem and harms any users who 511 are knowingly or unknowingly attempting to run 6to4. The strategic 512 solution is to deploy native IPv6, making Protocol 41 redundant. In 513 the short term, experimentation could be encouraged by allowing 514 Protocol 41 for certain users, while returning appropriate ICMP 515 responses as mentioned above. Unfortunately, if this is not done, 516 the 6to4 problem cannot be solved. 518 4.2.3. IPv4 prefix issues 520 Operators should never use "bogon" address space such as the example 521 of 1.1.1.0/24 for customers, since IPv4 exhaustion means that all 522 such addresses are likely to be in real use in the near future. 523 (Also see [I-D.ietf-intarea-shared-addressing-issues].) An operator 524 that is unable to immediately drop this practice should ensure that 525 192.88.99.1 generates IPv4 'destination unreachable'. It has been 526 suggested that they could also run a dummy 6to4 relay at that address 527 which always returns ICMPv6 'destination unreachable' as a 6to4 528 packet. However, these techniques are not very effective, since most 529 current end-user 6to4 implementations will ignore them. 531 If an operator is providing legitimate global addresses to customers 532 (neither RFC 1918 nor bogon addresses), and also running Carrier 533 Grade NAT (Large Scale NAT) between this address space and the global 534 address space of the Internet, then 6to4 cannot work properly. Such 535 an operator should also take care to return 'destination unreachable' 536 for 6to4 traffic. Alternatively, they could offer untranslated 537 address space to the customers concerned. 539 4.2.4. DNS issues 541 A customer who is intentionally using 6to4 may also need to create 542 AAAA records, and the operator should be able to support this, even 543 if the DNS service itself runs exclusively over IPv4. However, 544 customers should be advised to consider carefully whether their 6to4 545 service is sufficiently reliable for this. 547 Operators could, in principle, offer reverse DNS support for 6to4 548 users [RFC5158], although this is not straightforward for domestic 549 customers. 551 4.2.5. Rogue Router Advertisements 553 Paradoxically, operators in this category should consider whether 554 they need to defend themselves against rogue IPv6 RA messages 555 [RFC6105], since such messages may appear from devices seeking to 556 operate as 6to4 routers, and confuse any user devices with IPv6 557 enabled by default. Eventually, the measures being designed by the 558 IETF Source Address Validation Improvements (SAVI) working group will 559 assist with this problem. In the short term, IPv4-only operators may 560 choose to filter out packets with the IPv6 Ethertype (0x86DD) in 561 their access equipment; this will definitively remove rogue RA 562 packets. 564 4.2.6. Planning for IPv6 deployment 566 Enterprise operators who have complete administrative control of all 567 end-systems may choose to disable 6to4 in those systems as an 568 integral part of their plan to deploy IPv6. 570 Some IPv4 operators have chosen to install a 6to4 relay, connected 571 via an IPv6-in-IPv4 tunnel to an IPv6 operator, as a first step 572 before native IPv6 deployment. The routing guidelines in Section 4.4 573 would apply. However, offering genuine IPv6 service to interested 574 customers, even if tunneled, would generally be a better first step. 576 4.3. Consumer ISPs, and enterprise networks, that do support IPv6 578 Once an operator does support IPv6 service, whether experimentally or 579 in production, it is almost certain that users will get better 580 results using this service than by continuing to use 6to4. 581 Therefore, these operators are encouraged to advise their users to 582 disable 6to4 and they should not create DNS records for any 6to4 583 addresses. 585 Such an operator may automatically fall into one of the following two 586 categories (transit provider or content provider), so the guidelines 587 in Section 4.4 or in Section 4.5 will apply instead. 589 Operators in this category should make sure that no routers are 590 unintentionally or by default set up as active 6to4 relays. 591 Unmanaged 6to4 relays will be a source of problems. 593 Operators in this category should consider whether they need to 594 defend themselves against rogue RA messages with an RA Guard solution 595 [RFC6105]. If RA Guard is not available, it may help in some cases 596 if at least one legitimate IPv6 router per LAN supports [RFC4191] and 597 sets the Router Advertisement router preference bits to 01 (high 598 preference). Eventually, the measures being designed by the IETF 599 Source Address Validation Improvements (SAVI) working group will 600 assist with this problem. 602 4.4. Transit ISPs and Internet Exchange Points 604 We assume that transit ISPs have IPv6 connectivity. To reduce the 605 negative impact of Anycast 6to4 on all their client networks, it is 606 strongly recommended that they each run an Anycast 6to4 relay 607 service. This will have the additional advantage that they will 608 terminate the 6to4 IPv4 packets, and can then forward the 609 decapsulated IPv6 traffic according to their own policy. Otherwise, 610 they will blindly forward all the encapsulated IPv6 traffic to a 611 competitor who does run a relay. 613 Although most modern Internet Exchange Points do not offer IP layer 614 services, an IXP could choose to operate an Anycast 6to4 relay 615 service for the benefit of its customers. If so, it should follow 616 the recommendations in this section. 618 It is of critical importance that routing to this service is 619 carefully managed: 620 1. The IPv4 prefix 192.88.99.0/24 must be announced only towards 621 client IPv4 networks whose outbound 6to4 packets will be 622 accepted. 623 2. The IPv6 prefix 2002::/16 must be announced towards native IPv6. 624 The relay must accept all traffic towards 2002::/16 that reaches 625 it, so the scope reached by this announcement should be carefully 626 planned. It must reach all client IPv6 networks of the transit 627 ISP. If it reaches a wider scope, the relay will be offering a 628 free ride to non-clients. 629 3. As discussed in item 2 of Section 3, the choice of IPv4 source 630 address used when the relay sends 6to4 packets back towards a 631 6to4 user is important. The best choice is likely to be 632 192.88.99.1, not the relay's unicast IPv4 address, unless ingress 633 filtering is an issue. This is to avoid failure if the user is 634 behind a stateful firewall. 635 4. The relay should be capable of responding correctly to ICMPv6 636 echo requests encapsulated in IPv4 protocol 41, typically with 637 outer destination address 192.88.99.1 and inner destination 638 address 2002:c058:6301::. (As noted previously, some 6to4 hosts 639 are known to send echo requests with Hop Limit = 1, which allows 640 them to rapidly detect the presence or absence of a relay in any 641 case, but operators cannot rely on this behaviour.) 642 5. Protocol 41 must not be filtered in any IPv4 network or 643 firewalls. 644 6. As a matter of general practice, which is essential for 6to4 to 645 work well, IPv6 PMTUD must be possible, which means that ICMPv6 646 must not be blocked anywhere [RFC4890]. This also requires that 647 the relay has a sufficiently high ICMP error generation 648 threshold. For a busy relay, a typical default rate limit of 100 649 packets per second is too slow. On a busy relay, 1000pps or more 650 might be needed. If ICMPv6 "Packet Too Big" error messages are 651 rate-limited, users will experience PMTUD failure. 652 7. The relay must have adequate performance, and since load 653 prediction is extremely hard, it must be possible to scale it up 654 or, perhaps better, to replicate it as needed. Since the relay 655 process is stateless, any reasonable method of load sharing 656 between multiple relays will do. 657 8. The relay must of course be connected directly to global IPv4 658 space, with no NAT. 660 Operators in this category should make sure that no routers are 661 unintentionally or by default set up as active 6to4 relays. 662 Unmanaged 6to4 relays will be a source of problems. 664 4.5. Content providers and their ISPs 666 We assume that content providers and their ISPs have IPv6 667 connectivity, and that the servers are dual stacked. The following 668 applies to content servers as such, but equally to web hosting 669 servers, servers that form part of a content distribution network, 670 load balancers in front of a server farm, and HTTP caches. There is 671 a need to avoid the situation where a client host, configured with 672 Anycast 6to4, succeeds in sending an IPv6 packet to the server, but 673 the 6to4 return path fails as described above. To avoid this, there 674 must be a locally positioned 6to4 relay. Large content providers are 675 advised to operate their own relays, and ISPs should do so in any 676 case. There must be a 2002::/16 route from the content server to the 677 relay. As noted in the previous section, the corresponding route 678 advertisement must be carefully scoped, since any traffic that 679 arrives for 2002::/16 must be relayed. 681 Such a relay may be dedicated entirely to return traffic, in which 682 case it need not respond to the 6to4 anycast address. 684 Nevertheless, it seems wisest to ensure that when the relay sends 685 6to4 packets back towards a 6to4 user, they should have 192.88.99.1 686 as their IPv4 source address (not the relay's unicast IPv4 address). 687 As noted above, this is to avoid problems if the user is behind a 688 stateful firewall that drops UDP packets from addresses that have not 689 been seen in outbound traffic. However, it is also necessary that 690 192.88.99.1 is not blocked by upstream ingress filtering - this needs 691 to be tested. 693 Without careful engineering, there is nothing to make the return path 694 as short as possible. It is highly desirable to arrange the scope of 695 advertisements for 2002::/16 such that content providers have a short 696 path to the relay, and the relay should have a short path to the ISP 697 border. Care should be taken about shooting off advertisements for 698 2002::/16 into BGP4; they will become traffic magnets. If every ISP 699 with content provider customers operates a relay, there will be no 700 need for any of them to be advertised beyond each ISP's own 701 customers. 703 Protocol 41 must not be filtered in the ISP's IPv4 network or 704 firewalls. If the relays are placed outside the content provider's 705 firewall, the latter may filter protocol 41 if desired. 707 The relay must have adequate performance, and since load prediction 708 is extremely hard, it must be possible to scale it up or, perhaps 709 better, to replicate it as needed. Since the relay process is 710 stateless, any reasonable method of load sharing between multiple 711 relays will do. 713 The relay must of course be connected directly to global IPv4 space, 714 with no NAT. 716 An option is to embed the relay function directly in the content 717 server or first hop router. This is straightforward, since it can be 718 achieved by enabling a local 6to4 interface, and using it to route 719 2002::/16 for outbound packets. (This might not allow use of 720 192.88.99.1 as the source address.) Further details are to be found 721 at [Huston-b]. However, in this case Protocol 41 must be allowed by 722 the firewalls. 724 Content providers who do embed the relay function in this way could, 725 in theory, accept inbound 6to4 traffic as well. This is highly 726 unadvisable since, according the the rules of 6to4, they would then 727 have to relay traffic for other IPv6 destinations too. So they 728 should not be reachable via 192.88.99.1. Also, they should certainly 729 not create an AAAA record for their 6to4 address - their inbound IPv6 730 access should be native, and advertising a 6to4 address might well 731 lead to unicast reverse path forwarding (uRPF) [RFC3704] ingress 732 filtering problems. 734 To avoid the path MTU problem described above, content servers should 735 also set their IPv6 MTU to a safe value. From experience, 1280 bytes 736 (the minimum allowed for IPv6) is recommended; again see [Huston-b]. 737 Of course, ICMPv6 "Packet Too Big" must not be blocked or rate- 738 limited anywhere [RFC4890]. 740 Reverse DNS delegations are highly unlikely to exist for 6to4 741 clients, and are by no means universal for other IPv6 clients. 742 Content providers (and in fact all service providers) should not rely 743 on them as a pseudo-security check for IPv6 clients. 745 Operators and content providers should make sure that no routers are 746 unintentionally or by default set up as active 6to4 relays. 747 Unmanaged 6to4 relays will be a source of problems. 749 5. Tunnels Managed by ISPs 751 There are various ways, such as tunnel brokers [RFC3053], 6rd 752 [RFC5969], and L2TPv2 hub-and-spoke [RFC5571], by which Internet 753 Service Providers can provide tunneled IPv6 service to subscribers in 754 a managed way, in which the subscriber will acquire an IPv6 prefix 755 under a normal provider-based global IPv6 prefix. Most of the issues 756 described for 6to4 do not arise in these scenarios. However, for 757 IPv6-in-IPv4 tunnels used by clients behind a firewall, it is 758 essential that IPv4 Protocol 41 is not blocked. 760 As a matter of general practice, IPv6 PMTUD must be possible, which 761 means that ICMPv6 "Packet Too Big" must not be blocked or rate- 762 limited anywhere [RFC4890]. 764 6. Security Considerations 766 There is a general discussion of security issues for IPv6-in-IPv4 767 tunnels in [RFC6169] and [I-D.ietf-v6ops-tunnel-loops] discusses 768 possible malicious loops. [RFC3964] specifically discusses 6to4 769 security. In summary, tunnels create a challenge for many common 770 security mechanisms, simply because a potentially suspect packet is 771 encapsulated inside a harmless outer packet. All these 772 considerations apply to the automatic mechanisms discussed in this 773 document. However, it should be noted that if an operator provides 774 well managed servers and relays for 6to4, non-encapsulated IPv6 775 packets will pass through well defined points (the native IPv6 776 interfaces of those servers and relays) at which security mechanisms 777 may be applied. 779 A blanket recommendation to block Protocol 41 is not compatible with 780 mitigating the 6to4 problems described in this document. 782 7. IANA Considerations 784 This document makes no request of the IANA. 786 8. Acknowledgements 788 Useful comments and contributions were made by Emile Aben, Mikael 789 Abrahamsson, Tore Anderson, Hermin Anggawijaya, Jack Bates, Cameron 790 Byrne, Tim Chown, Remi Despres, Jason Fesler, Wes George, Philip 791 Homburg, Ray Hunter, Geoff Huston, Eric Kline, Victor Kuarsingh, 792 Martin Levy, David Malone, Alexey Melnikov, Martin Millnert, Keith 793 Moore, Gabi Nakibly, Michael Newbery, Phil Pennock, Pekka Savola, 794 Mark Smith, Nathan Ward, James Woodyatt, and others. 796 This document was produced using the xml2rfc tool [RFC2629]. 798 9. Change log [RFC Editor: please remove] 800 draft-ietf-v6ops-6to4-advisory-02: Updated with IETF Last Call and 801 IESG comments, 2011-06-22 803 draft-ietf-v6ops-6to4-advisory-01: Updated with WG Last Call 804 comments, 2011-04-26 806 draft-ietf-v6ops-6to4-advisory-00: WG draft, updated with WG 807 comments, 2011-03-31 809 draft-carpenter-v6ops-6to4-teredo-advisory-03: updated with 810 additional security reference and additional comments, 2011-03-12 812 draft-carpenter-v6ops-6to4-teredo-advisory-02: updated after further 813 comments, removed references to Teredo, 2011-02-24 815 draft-carpenter-v6ops-6to4-teredo-advisory-01: updated after WG 816 discussion, 2011-02-10 818 draft-carpenter-v6ops-6to4-teredo-advisory-00: original version, 819 2011-02-03 821 10. References 823 10.1. Normative References 825 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 826 via IPv4 Clouds", RFC 3056, February 2001. 828 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 829 RFC 3068, June 2001. 831 10.2. Informative References 833 [Aben] Aben, E., "6to4 - How Bad is it Really?", 2010, . 837 [Anderson] 838 Anderson, T., "IPv6 dual-stack client loss in Norway", 839 2010, . 841 [Huston-a] 842 Huston, G., "Flailing IPv6", 2010, 843 . 845 [Huston-b] 846 Huston, G., "Two Simple Hints for Dual Stack Servers", 847 2010, 848 . 850 [I-D.ietf-6man-rfc3484-revise] 851 Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC 852 3484 Default Address Selection for IPv6", 853 draft-ietf-6man-rfc3484-revise-03 (work in progress), 854 June 2011. 856 [I-D.ietf-behave-lsn-requirements] 857 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 858 and H. Ashida, "Common requirements for IP address sharing 859 schemes", draft-ietf-behave-lsn-requirements-01 (work in 860 progress), March 2011. 862 [I-D.ietf-intarea-shared-addressing-issues] 863 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 864 Roberts, "Issues with IP Address Sharing", 865 draft-ietf-intarea-shared-addressing-issues-05 (work in 866 progress), March 2011. 868 [I-D.ietf-v6ops-6to4-to-historic] 869 Troan, O., "Request to move Connection of IPv6 Domains via 870 IPv4 Clouds (6to4) to Historic status", 871 draft-ietf-v6ops-6to4-to-historic-04 (work in progress), 872 June 2011. 874 [I-D.ietf-v6ops-tunnel-loops] 875 Nakibly, G. and F. Templin, "Routing Loop Attack using 876 IPv6 Automatic Tunnels: Problem Statement and Proposed 877 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 878 progress), May 2011. 880 [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications] 881 Livingood, J., "IPv6 AAAA DNS Whitelisting Implications", 882 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06 883 (work in progress), June 2011. 885 [I-D.wing-v6ops-happy-eyeballs-ipv6] 886 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending 887 Towards Success with Dual-Stack Hosts", 888 draft-wing-v6ops-happy-eyeballs-ipv6-01 (work in 889 progress), October 2010. 891 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 892 E. Lear, "Address Allocation for Private Internets", 893 BCP 5, RFC 1918, February 1996. 895 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 896 June 1999. 898 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 899 RFC 2923, September 2000. 901 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 902 Tunnel Broker", RFC 3053, January 2001. 904 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 905 Networks", BCP 84, RFC 3704, March 2004. 907 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 908 6to4", RFC 3964, December 2004. 910 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 911 More-Specific Routes", RFC 4191, November 2005. 913 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 914 for IPv6 Hosts and Routers", RFC 4213, October 2005. 916 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 917 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 919 [RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", 920 RFC 5158, March 2008. 922 [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., 923 Toutain, L., and J. Tremblay, "Softwire Hub and Spoke 924 Deployment Framework with Layer Two Tunneling Protocol 925 Version 2 (L2TPv2)", RFC 5571, June 2009. 927 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 928 Infrastructures (6rd) -- Protocol Specification", 929 RFC 5969, August 2010. 931 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 932 Problem Statement", RFC 6104, February 2011. 934 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 935 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 936 February 2011. 938 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 939 Concerns with IP Tunneling", RFC 6169, April 2011. 941 [Savola] Savola, P., "Observations of IPv6 Traffic on a 6to4 942 Relay", ACM SIGCOMM CCR 35 (1) 23-28, 2006. 944 Author's Address 946 Brian Carpenter 947 Department of Computer Science 948 University of Auckland 949 PB 92019 950 Auckland, 1142 951 New Zealand 953 Email: brian.e.carpenter@gmail.com