idnits 2.17.1 draft-carpenter-v6ops-6to4-teredo-advisory-03.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 21 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 (March 12, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-6man-rfc3484-revise-01 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-tunnel-loops-04 == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 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 March 12, 2011 5 Expires: September 13, 2011 7 Advisory Guidelines for 6to4 Deployment 8 draft-carpenter-v6ops-6to4-teredo-advisory-03 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. The 16 intention of the advice is to minimise both user dissatisfaction and 17 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 September 13, 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 . . . . . . . . . . . . . . . . . . . . . 9 59 4.1. Vendor Issues . . . . . . . . . . . . . . . . . . . . . . 9 60 4.2. Consumer ISPs, and enterprise networks, that do not 61 support IPv6 in any way . . . . . . . . . . . . . . . . . 10 62 4.2.1. 6to4 as the first step to IPv6 operation . . . . . . . 11 63 4.3. Consumer ISPs, and enterprise networks, that do 64 support IPv6 . . . . . . . . . . . . . . . . . . . . . . . 12 65 4.4. Transit ISPs and Internet Exchange Points . . . . . . . . 12 66 4.5. Content providers and their ISPs . . . . . . . . . . . . . 13 67 5. Tunnels Managed by ISPs . . . . . . . . . . . . . . . . . . . 15 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 71 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 10. Informative References . . . . . . . . . . . . . . . . . . . . 16 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 1. Introduction 77 A technique for automatic tunneling of IPv6 over IPv4, intended for 78 situations where a user may wish to access IPv6-based services via a 79 network that does not support IPv6, was defined a number of years 80 ago. It is known as 6to4 [RFC3056], [RFC3068] and is quite widely 81 deployed in end systems, especially desktop and laptop computers. 82 Also, 6to4 is supported in a number of popular models of CPE routers, 83 some of which have it enabled by default, leading to quite widespread 84 unintentional deployment by end users. 86 Unfortunately, experience shows that the method has some problems in 87 current deployments that can lead to connectivity failures. These 88 failures either cause long retry delays or complete failures for 89 users trying to connect to services. In many cases, the user may be 90 quite unaware that 6to4 is in use, and when the user contacts a help 91 desk, in all probability the help desk is unable to correctly 92 diagnose the problem. Anecdotally, many help desks simply advise 93 users to disable IPv6, thus defeating the whole purpose of the 94 mechanism, which was to encourage early adoption of IPv6. 96 There is additional discussion of operational issues in 97 [I-D.vandevelde-v6ops-harmful-tunnels]. The main goal of the present 98 document is to offer advice to network operators on how to deal with 99 this situation more constructively than by disabling 6to4. It 100 briefly describes the principle of operation, then describes the 101 problems observed, and finally offers specific advice on the 102 available methods of avoiding the problems. Note that some of this 103 advice applies to ISPs that do not yet support IPv6, since their 104 customers and help desks are significantly affected in any case. 105 Other advice applies to content providers. 107 We do not discuss here details of this situation that are mainly 108 outside the scope of network operators: 109 1. Operating system preferences between IPv4 and IPv6 when both 110 appear to be available [I-D.ietf-6man-rfc3484-revise]. 111 2. Ensuring that application software deals gracefully with 112 connectivity problems [I-D.wing-v6ops-happy-eyeballs-ipv6]. 113 3. Some content providers have chosen to avoid the problem by hiding 114 their IPv6 address except from customers of pre-qualified 115 networks [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]. 117 Note to readers of earlier versions: references to Teredo have been 118 removed from this document. Sorry about the file name. 120 2. Principles of Operation 122 There are two variants of 6to4 which are referred to here as "Router 123 6to4" and "Anycast 6to4". To understand Anycast 6to4, it is 124 necessary first to understand Router 6to4. 126 2.1. Router 6to4 128 Router 6to4 is the original version, documented in [RFC3056]. The 129 model assumes that a user site operates native IPv6, but that its ISP 130 provides no IPv6 service. The site border router acts as a 6to4 131 router. If its external global 32-bit IPv4 address is V4ADDR, the 132 site automatically inherits the IPv6 prefix 2002:V4ADDR::/48. (The 133 explanation in RFC 3056 is somewhat confusing, as it refers to the 134 obsolete "Top Level Aggregator" terminology.) The prefix 2002: 135 V4ADDR::/48 will be used and delegated for IPv6 service within the 136 user site. 138 Consider two such site border routers, with global IPv4 addresses 139 192.0.2.170 and 190.0.2.187, and therefore inheriting the IPv6 140 prefixes 2002:c000:2aa::/48 and 2002:c000:2bb::/48 respectively. The 141 routers can exchange IPv6 packets by encapsulating them in IPv4 using 142 protocol number 41, and sending them to each other at their 143 respective IPv4 addresses. In fact, any number of 6to4 routers 144 connected to the IPv4 network can directly exchange IPv6 packets in 145 this way. 147 Some 6to4 routers are also configured as "Relay routers." They 148 behave as just described, but in addition they obtain native IPv6 149 connectivity with a normal IPv6 prefix. They announce an IPv6 route 150 to 2002::/16. For example, assume that the 6to4 router at 151 190.0.2.187 is a relay router, whose address on the 6to4 side is 152 2002:c000:2bb::1. Suppose that a host with the 6to4 address 2002: 153 c000:2aa::123 sends an IPv6 packet to a native IPv6 destination such 154 as 2001:db8:123:456::321. Assume that the 6to4 router at 192.0.2.170 155 has its IPv6 default route set to 2002:c000:2bb::1, i.e. the relay. 156 The packet will be delivered to the relay, encapsulated in IPv4. 157 After decapsulation, the relay will forward the packet into native 158 IPv6 for delivery. When the remote host replies, the packet (source 159 2001:db8:123:456::321, destination 2002:c000:2aa::123) will find a 160 route to 2002::/16 and hence be delivered to a 6to4 relay. The 161 process will be reversed and the packet will be encapsulated and 162 forwarded to the 6to4 router at 192.0.2.170 for final delivery. 164 Note that this process does not require the same relay to be used in 165 both directions. The outbound packet will go to whichever relay is 166 configured as the default IPv6 router at the source router, and the 167 return packet will go to whichever relay is announcing a route to 168 2002::/16 in the vicinity of the remote IPv6 host. 170 There are of course many further details in RFC 3056, most of which 171 are irrelevant to current operational problems. 173 2.2. Anycast 6to4 175 Router 6to4 assumes that 6to4 routers and relays will be managed and 176 configured cooperatively. In particular, 6to4 sites need to find a 177 relay router willing to carry their outbound traffic, which becomes 178 their default IPv6 router (except for 2002::/16). The objective of 179 the anycast variant, defined in [RFC3068], is to avoid any need for 180 such configuration. The intention was to make the solution available 181 for small or domestic users, even those with a single host or simple 182 home gateway rather than a border router. This is achieved quite 183 simply, by defining 192.88.99.1 as the default IPv4 address for a 184 6to4 relay, and therefore 2002:c058:6301:: as the default IPv6 router 185 address for a 6to4 site. 187 Since Anycast 6to4 implies a default configuration for the user site, 188 it does not require any particular user action. It does require an 189 IPv4 anycast route to be in place to a relay at 192.88.99.1. As with 190 Router 6to4, there is no requirement that the return path goes 191 through the same relay. 193 3. Problems Observed 195 It should be noted that Router 6to4 was not designed to be an 196 unmanaged solution. Quite the contrary: RFC 3056 contains a number 197 of operational recommendations intended to avoid routing issues. In 198 practice, there are few if any deployments of Router 6to4 following 199 these recommendations. Mostly, Anycast 6to4 has been deployed. In 200 this case, the user site (either a single host or a small broaband 201 gateway) discovers that it doesn't have native IPv6 connectivity, but 202 that it does have a global IPv4 address and can resolve AAAA queries, 203 and therefore assumes that it can send 6to4 packets to 192.88.99.1. 205 Empirically, 6to4 appears to suffer from a significant level of 206 connection failure; see 207 208 and . In 209 experiments conducted on a number of dual stack web servers, the TCP 210 connection failure rate has been measured. In these experiments, the 211 client's connection attempt to a server was considered to have failed 212 when the server received a TCP SYN packet and sent a SYN/ACK packet 213 in response, but received no ACK packet to complete the initial TCP 214 3-way handshake. The experiment conducted by Aben recorded a failure 215 rate of between 9% and 20% of all 6to4 connection attempts. The 216 experiment conducted by Huston has recorded a failure rate of between 217 9% and 19% of all 6to4 clients. In this latter experiment it was 218 further noted that between 65% to 80% of all 6to4 clients who failed 219 to connect using 6to4 were able to make a successful connection using 220 IPv4, while the remainder did not make any form of IPv4 connection 221 attempt, successful or otherwise, using the mapped IPv4 address as a 222 source address. No connection attempts were recorded by the server 223 using embedded RFC1918 IPv4 addresses. 225 There have been several possible reasons offered for this form of 226 6to4 connection failure. One is the use of private IPv4 addresses 227 embedded in the 6to4 address, making the return path for the 6to4 228 tunnel infeasible, and the second is the use of local filters and 229 firewalls that drop incoming IP packets that use IP protocol 41. If 230 the former case were prevalent it would be reasonable to expect that 231 a significant proportion of failed 6to4 connections would use 232 embedded IPv4 addresses that are either drawn from the private use 233 (RFC 1918) address ranges, contrary to RFC 3056, or from addresses 234 that are not announced in the Internet's IPv4 inter-domain routing 235 table. Neither case was observed to any significant volume in the 236 experiments conducted by Huston. Furthermore, the experimental 237 conditions were varied to use a return 6to4 tunnel with either the 238 native IPv4 source address of the dual stack server or an IPv4 source 239 address of 192.88.99.1. No change in the 6to4 connection failure 240 rate was observed between these two configurations; however, other 241 operators have reported significant problems when replying from the 242 native address, caused by stateful firewalls at the user site. Given 243 that the server used its own 6to4 relay for the return path, the only 244 difference in the IP packet itself between the successful IPv4 245 connections and the failed 6to4 connections was the IP protocol 246 number, which was 6 (TCP) for the successful IPv4 connections and 41 247 (IPv6 payload) for the failed 6to4 connections. The inference from 248 these experiments is that one likely reason for the high connection 249 failure rate for 6to4 connections is the use of local filters close 250 to the end-user that block incoming packets with protocol 41. 252 In a dual stack context this connection failure rate was effectively 253 masked by the ability of the client system to recover from the 254 failure and make a successful connection using IPv4. In this case 255 the only effect on the client system was a delay in making the 256 connection of between 7 and 20 seconds as the client's system timed 257 out on the 6to4 connection attempts (see 258 [I-D.wing-v6ops-happy-eyeballs-ipv6]). 260 This experience and further analysis shows that specific operational 261 problems with Anycast 6to4 include: 263 1. Outbound Black Hole: 192.88.99.1 does not generate 'destination 264 unreachable' but in fact packets sent to that address are 265 dropped. This can happen due to routing or firewall 266 configuration, or even because the relay that the packets happen 267 to reach contains an ACL such that they are discarded. 269 This class of problem arises because the user's ISP is accepting 270 a route to 192.88.99.0/24 despite the fact that it doesn't go 271 anywhere useful. Either the user site or its ISP is dropping 272 outbound Protocol 41 traffic, or the upstream operator is 273 unwilling to accept incoming 6to4 packets from the user's ISP. 274 The latter is superficially compatible with the design of Router 275 6to4 (referred to as "unwilling to relay" in RFC 3056). However, 276 the simple fact of announcing a route to 192.88.99.0/24 in IPv4, 277 coupled with the behavior described in RFC 3068, amounts to 278 announcing a default route for IPv6 to all 6to4 sites that 279 receive the IPv4 route. This violates the assumptions of RFC 280 3056. 282 The effect of this problem on users is that their IPv6 stack 283 believes that it has 6to4 connectivity, but in fact all outgoing 284 IPv6 packets are black-holed. The prevalence of this problem is 285 hard to measure, since the resulting IPv6 packets can never be 286 observed from the outside. 287 2. Inbound Black Hole: In this case, 6to4 packets sent to 288 192.88.99.1 are correctly delivered to a 6to4 relay, and reply 289 packets are returned, but they are dropped by an inbound Protocol 290 41 filter. As far as the user is concerned, the effect is the 291 same as the previous case: IPv6 is a black hole. Many enterprise 292 neworks are believed to be set up in this way. Connection 293 attempts due to this case can be observed by IPv6 server 294 operators, in the form of SYN packets from addresses in 2002::/16 295 followed by no response to the resulting SYN/ACK. From the 296 experiments cited above, this appears to be a significant problem 297 in practice. 298 3. No Return Relay: If the Outbound Black Hole problem does not 299 occur, i.e. the outgoing packet does reach the intended native 300 IPv6 destination, the target system will send a reply packet, to 301 2002:c000:2aa::123 in our example above. Then 2002::/16 may or 302 may not be successfully routed. If it is not routed, the packet 303 will be dropped (hopefully with 'destination unreachable'). 304 According to RFC 3056, an unwilling relay "MUST NOT advertise any 305 2002:: routing prefix into the native IPv6 domain"; therefore, 306 conversely, if this prefix is advertised the relay must relay 307 packets regardless of source and destination. However, in 308 practice the problem arises that some relays reject packets that 309 they should relay, based on their IPv6 source address. 311 Whether the native IPv6 destination has no route to 2002::/16, or 312 it turns out to have a route to an unwilling relay, the effect is 313 the same: all return IPv6 packets are black-holed. While there 314 is no direct evidence of the prevalence of this problem, it 315 certainly exists in practice. 316 4. Large RTT: In the event that none of the above three problems 317 applies, and a two-way path does in fact exist between a 6to4 318 host and a native host, the round trip time may be quite large 319 and variable since the paths to the two relays are unmanaged and 320 may be complex. Overloaded relays might also cause highly 321 variable RTT. 322 5. PMTUD Failure: A common link MTU size observed on the Internet 323 today is 1500 bytes. However, when using 6to4 the path MTU is 324 less than this due to the encapsulation header. Thus a 6to4 325 client will normally see a link MTU that is less than 1500, but a 326 native IPv6 server will see 1500. Path MTU Discovery does not 327 always work, and this can lead to connectivity failures. Even if 328 a TCP SYN/ACK exchange works, TCP packets with full size payloads 329 may simply be lost. These failures are disconcerting even to an 330 informed user, since a standard 'ping' from the client to the 331 server will succeed, because it generates small packets, and the 332 successful SYN/ACK exchange can be traced. Also, the failure may 333 occur on some paths but not others, so a user may be able to 334 fetch web pages from one site, but only ping another. 335 6. Reverse DNS Failure: Typically a 6to4-addressed host will not 336 have a reverse DNS delegation. If reverse DNS is used as a 337 pseudo-security check, it will fail. 338 7. Bogus Address Failure: By design, 6to4 does not work and will not 339 activate itself if the available V4ADDR is a private address 340 [RFC1918]. However it will also not work if the available V4ADDR 341 is a "bogon", i.e. a global address that is being used by the 342 operator as a private address. A common case of this is a legacy 343 wireless network using 1.1.1.0/24 as if it was a private address. 344 In this case, 6to4 will assume it is connected to the global 345 Internet, but there is certainly no working return path. 347 This failure mode will also occur if an ISP is operating a 348 Carrier Grade NAT between its customers and the Internet, and is 349 using global public address space as if it were private space to 350 do so. 351 8. Faulty 6to4 Implementations: It has been reported that some 6to4 352 implementations attempt to activate themselves even when the 353 available IPv4 address is an RFC 1918 address. This is in direct 354 contradiction to RFC 3056, and will produce exactly the same 355 failure mode as Bogus Address Failure. It is of course outside 356 the ISP's control. 358 9. Difficult Fault Diagnosis: The existence of all the above failure 359 modes creates a problem of its own: very difficult fault 360 diagnosis, especially if the only symptom reported by a user is 361 slow access to web pages, caused by a long timeout before 362 fallback to IPv4. Tracking down anycast routing problems and 363 PMTUD failures is particularly hard. 365 The practical impact of the above problems, which are by no means 366 universal as there is considerable successful use of Anycast 6to4, 367 has been measured at a fraction of 1% loss of attempted connections 368 to content servers (see ). While this seems 369 low, it amounts to a significant financial impact for content 370 providers. Also, end users frustrated by the poor response times 371 caused by fall-back to IPv4 connectivity 372 [I-D.wing-v6ops-happy-eyeballs-ipv6] are considered likely to 373 generate help desk calls with their attendant costs. 375 A rather different operational problem caused incidentally by 6to4 is 376 that, according to observations made by Tim Chown and James Morse at 377 the University of Southampton, rogue Router Advertisements [RFC6104] 378 predominantly convey a 2002::/16 prefix. This appears to be due to 379 misbehaviour by devices acting as local IPv6 routers or connection- 380 sharing devices but issuing RA messages on the wrong interface. 382 4. Advisory Guidelines 384 There are several types of operator involved, willingly or 385 unwillingly, in the Anycast 6to4 scenario and they will all suffer if 386 things work badly. There is a clear incentive for each of them to 387 take appropriate action, as described below. 389 This document avoids formal normative language, because it is highly 390 unlikely that the guidelines apply universally. Each operator will 391 make its own decisions about which of the following guidelines are 392 useful in its specific scenario. 394 4.1. Vendor Issues 396 Although this document is aimed principally at operators, there are 397 some steps that implementers and vendors of 6to4 should take. 398 1. Some vendors of routers, including customer premises equipment, 399 have not only included support for 6to4 in their products, but 400 have enabled it by default. This is bad practice - it should 401 always be a conscious decision by a user to enable 6to4. Many of 402 the above problems only occur due to unintentional deployment of 403 6to4. 405 2. Similarly, host operating systems should not enable Anycast 6to4 406 by default; it should always be left to the user to switch it on. 407 3. Any 6to4 implementation that attempts to activate itself when the 408 available IPv4 address is an RFC 1918 address is faulty and needs 409 to be updated. 410 4. 6to4 implementations should adopt updated IETF recommendations on 411 address selection [I-D.ietf-6man-rfc3484-revise]. 412 5. 6to4 router or connection-sharing implementations must avoid 413 issuing rogue RAs [RFC6104]. 415 4.2. Consumer ISPs, and enterprise networks, that do not support IPv6 416 in any way 418 To reduce the negative impact of Anycast 6to4 deployed (probably 419 unknowingly) by users, and consequent user dissatisfaction and help 420 desk calls, such ISPs should check in sequence: 421 1. Does the ISP have a route to 192.88.99.1? (This means an 422 explicit route, or knowledge that the default upstream provider 423 has an explicit route. A default route doesn't count!) 424 2. If so, is it functional and stable? 425 3. If so, is the ping time reasonably short? 426 4. If so, does the relay willingly accept 6to4 traffic from the 427 ISP's IPv4 prefixes? (Note that this is an administrative as 428 well as a technical question - is the relay's operator willing to 429 accept the traffic?) 431 Unless the answer to all these questions is 'yes', subscribers will 432 be no worse off, and possibly better off, if the route to 192.88.99.1 433 is blocked and generates an IPv4 'destination unreachable'. There is 434 little operational experience with this, however. 436 Some implementations also perform some form of 6to4 relay 437 qualification. For example, one host implementation (Windows) tests 438 the Protocol 41 reachability by sending an ICMPv6 echo request with 439 Hop Limit=1 to the relay, expecting a response or Hop Limit exceeded 440 error back. Lack of any response indicates that the 6to4 relay does 441 not work so 6to4 is turned off [Savola]. 443 A more constructive approach for such an ISP is to seek out a transit 444 provider who is indeed willing to offer outbound 6to4 relay service, 445 so that the answer to each of the questions above is positive. 447 In any case, such ISPs should always allow protocol 41 through their 448 network and firewalls. Not only is this a necessary condition for 449 6to4 to work, but it also allows users who want to use a configured 450 IPv6 tunnel service to do so. 452 Some operators, particularly enterprise networks, silently block 453 Protocol 41 on security grounds. Doing this on its own is bad 454 practice, since it contributes to the problem and harms any users who 455 are knowingly or unknowingly attempting to run 6to4. The strategic 456 solution is to deploy native IPv6, making Protocol 41 redundant. In 457 the short term, experimentation could be encouraged by allowing 458 Protocol 41 for certain users, while returning appropriate ICMP 459 responses as mentioned above. Unfortunately, if this is not done, 460 the 6to4 problem cannot be solved. 462 Operators should never use "bogon" address space such as the example 463 of 1.1.1.0/24 for customers, since IPv4 exhaustion means that all 464 such addresses are likely to be in real use in the near future. 465 (Also see [I-D.ietf-intarea-shared-addressing-issues].) An operator 466 that is unable to immediately drop this practice should ensure that 467 192.88.99.1 generates IPv4 'destination unreachable'. It has been 468 suggested that they could also run a dummy 6to4 relay at that address 469 which always returns ICMPv6 'destination unreachable' as a 6to4 470 packet. However, these techniques are not very effective, since most 471 current end-user 6to4 implementations will ignore them. 473 If an operator is providing legitimate global addresses to customers 474 (neither RFC 1918 nor bogon addresses), and also running Carrier 475 Grade NAT (Large Scale NAT) between this address space and the global 476 address space of the Internet, then 6to4 cannot work properly. Such 477 an operator should also take care to return 'destination unreachable' 478 for 6to4 traffic. Alternatively, they could offer untranslated 479 address space to the customers concerned. 481 A customer who is intentionally using 6to4 may also need to create 482 AAAA records, and the operator should be able to support this, even 483 if the DNS service itself runs exclusively over IPv4. However, 484 customers should be advised to consider carefully whether their 6to4 485 service is sufficiently reliable for this. 487 Operators could, in principle, offer reverse DNS support for 6to4 488 users [RFC5158], although this is not straightforward for domestic 489 customers. 491 Finally, enterprise operators who have complete administrative 492 control of all end-systems may choose to disable 6to4 in those 493 systems as an integral part of their plan to deploy IPv6. 495 4.2.1. 6to4 as the first step to IPv6 operation 497 An IPv4 operator could choose to install a well-managed 6to4 relay, 498 connected to an IPv6-in-IPv4 tunnel to an IPv6 operator. This could 499 serve as a small first step before the operator proceeds to native 500 IPv6 deployment. The routing guidelines in Section 4.4 would apply. 502 4.3. Consumer ISPs, and enterprise networks, that do support IPv6 504 Once an operator does support IPv6 service, whether experimentally or 505 in production, it is almost certain that users will get better 506 results using this service than by continuing to use 6to4. 507 Therefore, these operators are encouraged to advise their users to 508 disable 6to4 and they should not create DNS records for any 6to4 509 addresses. 511 Such an operator may automatically fall into one of the following two 512 categories (transit provider or content provider), so the guidelines 513 in Section 4.4 or in Section 4.5 will apply instead. 515 Operators in this category should make sure that no routers are 516 unintentionally or by default set up as active 6to4 relays. 517 Unmanaged 6to4 relays will be a source of problems. 519 Operators in this category should consider whether they need to 520 defend themselves against rogue RA messages [RFC6105]. 522 4.4. Transit ISPs and Internet Exchange Points 524 We assume that transit ISPs and IXPs have IPv6 connectivity. To 525 reduce the negative impact of Anycast 6to4 on all their client 526 networks, it is strongly recommended that they each run an Anycast 527 6to4 relay service. This will have the additional advantage that 528 they will terminate the 6to4 IPv4 packets, and can then forward the 529 decapsulated IPv6 traffic according to their own policy. Otherwise, 530 they will blindly forward all the encapsulated IPv6 traffic to a 531 competitor who does run a relay. 533 It is of critical importance that routing to this service is 534 carefully managed: 535 1. The IPv4 prefix 192.88.99.0/24 must be announced only towards 536 client IPv4 networks whose outbound 6to4 packets will be 537 accepted. 538 2. The IPv6 prefix 2002::/16 must be announced towards native IPv6. 539 The relay must accept all traffic towards 2002::/16 that reaches 540 it, so the scope reached by this announcement should be carefully 541 planned. It must reach all client IPv6 networks of the transit 542 ISP or IXP. If it reaches a wider scope, the relay will be 543 offering a free ride to non-clients. 544 3. The evidence is mixed, but it seems best to ensure that when the 545 relay sends 6to4 packets back towards a 6to4 user, they should 546 have 192.88.99.1 as their IPv4 source address (not the relay's 547 unicast IPv4 address). This is to avoid problems if the user is 548 behind a stateful firewall that drops inbound packets from 549 addresses that have not been seen in outbound traffic. 551 4. The relay should be capable of responding correctly to ICMPv6 552 echo requests encapsulated in IPv4 protocol 41, typically with 553 outer destination address 192.88.99.1 and inner destination 554 address 2002:c058:6301::. (As noted previously, some 6to4 hosts 555 are known to send echo requests with Hop Limit = 1, which allows 556 them to rapidly detect the presence or absence of a relay in any 557 case, but operators cannot rely on this behaviour.) 558 5. Protocol 41 must not be filtered in any IPv4 network or 559 firewalls. 560 6. As a matter of general practice, which is essential for 6to4 to 561 work well, IPv6 PMTUD must be possible, which means that ICMPv6 562 must not be blocked anywhere [RFC4890]. This also requires that 563 the relay has a sufficiently high ICMP error generation 564 threshold. For a busy relay, a typical default rate limit of 100 565 packets per second is too slow. On a busy relay, 1000pps or more 566 might be needed. If ICMPv6 "Packet too Big" error messages are 567 rate-limited, users will experience PMTUD failure. 568 7. The relay must have adequate performance, and since load 569 prediction is extremely hard, it must be possible to scale it up 570 or, perhaps better, to replicate it as needed. Since the relay 571 process is stateless, any reasonable method of load sharing 572 between multiple relays will do. 573 8. The relay must of course be connected directly to global IPv4 574 space, with no NAT. 576 Operators in this category should make sure that no routers are 577 unintentionally or by default set up as active 6to4 relays. 578 Unmanaged 6to4 relays will be a source of problems. 580 4.5. Content providers and their ISPs 582 We assume that content providers and their ISPs have IPv6 583 connectivity, and that content servers are dual stacked. There is a 584 need to avoid the situation where a client host, configured with 585 Anycast 6to4, suceeds in sending an IPv6 packet to the server, but 586 the 6to4 return path fails as described above. To avoid this, there 587 must be a locally positioned 6to4 relay. Large content providers are 588 advised to operate their own relays, and ISPs should do so in any 589 case. There must be a 2002::/16 route from the content server to the 590 relay. As noted in the previous section, the corresponding route 591 advertisement must be carefully scoped, since any traffic that 592 arrives for 2002::/16 must be relayed. 594 Such a relay may be dedicated entirely to return traffic, in which 595 case it need not respond to the 6to4 anycast address. 597 Nevertheless, it seems wisest to ensure that when the relay sends 598 6to4 packets back towards a 6to4 user, they should have 192.88.99.1 599 as their IPv4 source address (not the relay's unicast IPv4 address). 600 As noted above, this is to avoid problems if the user is behind a 601 stateful firewall that drops UDP packets from addresses that have not 602 been seen in outbound traffic. However, it is also necessary that 603 192.88.99.1 is not blocked by upstream ingress filtering - this needs 604 to be tested. 606 Without careful engineering, there is nothing to make the return path 607 as short as possible. It is highly desirable to arrange the scope of 608 advertisements for 2002::/16 such that content providers have a short 609 path to the relay, and the relay should have a short path to the ISP 610 border. Care should be taken about shooting off advertisements for 611 2002::/16 into BGP4; they will become traffic magnets. If every ISP 612 with content provider customers operates a relay, there will be no 613 need for any of them to be advertised beyond each ISP's own 614 customers. 616 Protocol 41 must not be filtered in the ISP's IPv4 network or 617 firewallls. If the relays are placed outside the content provider's 618 firewall, the latter may filter protocol 41 if desired. 620 The relay must have adequate performance, and since load prediction 621 is extremely hard, it must be possible to scale it up or, perhaps 622 better, to replicate it as needed. Since the relay process is 623 stateless, any reasonable method of load sharing between multiple 624 relays will do. 626 The relay must of course be connected directly to global IPv4 space, 627 with no NAT. 629 An option for content servers is to embed the relay function directly 630 in the content server. This is in fact trivial, since it can be 631 achieved by enabling a local 6to4 interface on the server, and using 632 it to route 2002::/16 for outbound packets. (This might not allow 633 use of 192.88.99.1 as the source address.) Further details are to be 634 found at . 635 However, in this case Protocol 41 must be allowed by the firewalls. 637 Content providers who do embed the relay function in this way could, 638 in theory, accept inbound 6to4 traffic as well. This is highly 639 unadvisable since, according the the rules of 6to4, they would then 640 have to relay traffic for other IPv6 destinations too. So they 641 should not be reachable via 192.88.99.1. Also, they should certainly 642 not create an AAAA record for their 6to4 address - their inbound IPv6 643 access should be native, and advertising a 6to4 address might well 644 lead to uRPF ingress filtering problems. 646 To avoid the path MTU problem described above, content servers should 647 also set their IPv6 MTU to a safe value. From experience, 1280 bytes 648 (the minimum allowed for IPv6) is recommended; again see 649 . Of course, 650 ICMPv6 "Message too Big" must not be blocked or rate-limited anywhere 651 [RFC4890]. 653 Reverse DNS delegations are highly unlikely to exist for 6to4 654 clients, and are by no means universal for other IPv6 clients. 655 Content providers (and in fact all service providers) should not rely 656 on them as a pseudo-security check for IPv6 clients. 658 Operators and content providers should make sure that no routers are 659 unintentionally or by default set up as active 6to4 relays. 660 Unmanaged 6to4 relays will be a source of problems. 662 5. Tunnels Managed by ISPs 664 There are various ways, such as tunnel brokers [RFC3053], 6rd 665 [RFC5969], L2TPv2 hub-and-spoke [RFC5571], and the proposed 6a44 666 [I-D.despres-softwire-6a44], by which Internet Service Providers can 667 provide tunneled IPv6 service to subscribers in a managed way, in 668 which the subscriber will acquire an IPv6 prefix under a normal 669 provider-based global IPv6 prefix. Most of the issues described for 670 6to4 do not arise in these scenarios. However, for IPv6-in-IPv4 671 tunnels used by clients behind a firewall, it is essential that IPv4 672 Protocol 41 is not blocked. 674 As a matter of general practice, IPv6 PMTUD must be possible, which 675 means that ICMPv6 "Message too Big" must not be blocked or rate- 676 limited anywhere [RFC4890]. 678 6. Security Considerations 680 There is a general discussion of security issues for IPv6-in-IPv4 681 tunnels in [I-D.ietf-v6ops-tunnel-security-concerns], and 682 [I-D.ietf-v6ops-tunnel-loops] discusses possible malicious loops. 683 [RFC3964] specifically discusses 6to4 security. In summary, tunnels 684 create a challenge for many common security mechanisms, simply 685 because a potentially suspect packet is encapsulated inside a 686 harmless outer packet. All these considerations apply to the 687 automatic mechanisms discussed in this document. However, it should 688 be noted that if an operator provides well managed servers and relays 689 for 6to4, non-encapsulated IPv6 packets will pass through well 690 defined points (the native IPv6 interfaces of those servers and 691 relays) at which security mechanisms may be applied. 693 A blanket recommendation to block Protocol 41 is not compatible with 694 mitigating the 6to4 problems described in this document. 696 7. IANA Considerations 698 This document makes no request of the IANA. 700 8. Acknowledgements 702 Useful comments and contributions were made by Emile Aben, Tore 703 Anderson, Jack Bates, Cameron Byrne, Remi Despres, Jason Fesler, Wes 704 George, Geoff Huston, Eric Kline, Victor Kuarsingh, Martin Levy, 705 David Malone, Martin Millnert, Keith Moore, Gabi Nakibly, Michael 706 Newbery, Pekka Savola, Mark Smith, Nathan Ward, James Woodyatt, and 707 others. 709 This document was produced using the xml2rfc tool [RFC2629]. 711 9. Change log 713 draft-carpenter-v6ops-6to4-teredo-advisory-03: updated with 714 additional security reference and addditional comments, 2011-03-12 716 draft-carpenter-v6ops-6to4-teredo-advisory-02: updated after further 717 comments, removed references to Teredo, 2011-02-24 719 draft-carpenter-v6ops-6to4-teredo-advisory-01: updated after WG 720 discussion, 2011-02-10 722 draft-carpenter-v6ops-6to4-teredo-advisory-00: original version, 723 2011-02-03 725 10. Informative References 727 [I-D.despres-softwire-6a44] 728 Despres, R., Carpenter, B., and S. Jiang, "Native IPv6 729 Across NAT44 CPEs (6a44)", draft-despres-softwire-6a44-01 730 (work in progress), October 2010. 732 [I-D.ietf-6man-rfc3484-revise] 733 Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC 734 3484 Default Address Selection for IPv6", 735 draft-ietf-6man-rfc3484-revise-01 (work in progress), 736 October 2010. 738 [I-D.ietf-intarea-shared-addressing-issues] 739 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 740 Roberts, "Issues with IP Address Sharing", 741 draft-ietf-intarea-shared-addressing-issues-05 (work in 742 progress), March 2011. 744 [I-D.ietf-v6ops-tunnel-loops] 745 Nakibly, G. and F. Templin, "Routing Loop Attack using 746 IPv6 Automatic Tunnels: Problem Statement and Proposed 747 Mitigations", draft-ietf-v6ops-tunnel-loops-04 (work in 748 progress), March 2011. 750 [I-D.ietf-v6ops-tunnel-security-concerns] 751 Krishnan, S., Thaler, D., and J. Hoagland, "Security 752 Concerns With IP Tunneling", 753 draft-ietf-v6ops-tunnel-security-concerns-04 (work in 754 progress), October 2010. 756 [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications] 757 Livingood, J., "IPv6 AAAA DNS Whitelisting Implications", 758 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 759 (work in progress), February 2011. 761 [I-D.vandevelde-v6ops-harmful-tunnels] 762 Velde, G., Troan, O., and T. Chown, "Non-Managed IPv6 763 Tunnels considered Harmful", 764 draft-vandevelde-v6ops-harmful-tunnels-01 (work in 765 progress), August 2010. 767 [I-D.wing-v6ops-happy-eyeballs-ipv6] 768 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending 769 Towards Success with Dual-Stack Hosts", 770 draft-wing-v6ops-happy-eyeballs-ipv6-01 (work in 771 progress), October 2010. 773 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 774 E. Lear, "Address Allocation for Private Internets", 775 BCP 5, RFC 1918, February 1996. 777 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 778 June 1999. 780 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 781 Tunnel Broker", RFC 3053, January 2001. 783 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 784 via IPv4 Clouds", RFC 3056, February 2001. 786 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 787 RFC 3068, June 2001. 789 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 790 6to4", RFC 3964, December 2004. 792 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 793 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 795 [RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", 796 RFC 5158, March 2008. 798 [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., 799 Toutain, L., and J. Tremblay, "Softwire Hub and Spoke 800 Deployment Framework with Layer Two Tunneling Protocol 801 Version 2 (L2TPv2)", RFC 5571, June 2009. 803 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 804 Infrastructures (6rd) -- Protocol Specification", 805 RFC 5969, August 2010. 807 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 808 Problem Statement", RFC 6104, February 2011. 810 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 811 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 812 February 2011. 814 [Savola] Savola, P., "Observations of IPv6 Traffic on a 6to4 815 Relay", ACM SIGCOMM CCR 35 (1) 23-28, 2006. 817 Author's Address 819 Brian Carpenter 820 Department of Computer Science 821 University of Auckland 822 PB 92019 823 Auckland, 1142 824 New Zealand 826 Email: brian.e.carpenter@gmail.com