idnits 2.17.1 draft-chown-v6ops-call-to-arms-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 7, 2011) is 4705 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-happy-eyeballs-02 == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05 == Outdated reference: A later version (-04) exists of draft-chen-mif-happy-eyeballs-extension-01 == Outdated reference: A later version (-05) exists of draft-ietf-6man-rfc3484-revise-02 == Outdated reference: A later version (-05) exists of draft-arkko-ipv6-only-experience-03 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Chown 3 Internet-Draft University of Southampton 4 Intended status: Informational M. Ford 5 Expires: December 9, 2011 Internet Society 6 S. Venaas 7 Cisco Systems 8 June 7, 2011 10 World IPv6 Day Call to Arms 11 draft-chown-v6ops-call-to-arms-03 13 Abstract 15 The Internet Society (ISOC) has declared that June 8th 2011 will be 16 World IPv6 Day, on which some major organisations are going to make 17 their content available over IPv6. With the likes of Google and 18 Facebook providing IPv6 access to their production services and 19 domains, it is very likely we will see more IPv6 traffic flowing 20 across the Internet than has ever been seen before. With this in 21 mind, it seems timely to issue a call to arms for systems and network 22 administrators to review their organisation's IPv6 capabilities in 23 order to mitigate common causes of IPv6 connectivity problems in 24 advance of the day. The increased traffic on World IPv6 Day should 25 also create an excellent opportunity to observe the behaviour and 26 performance of IPv6; it is thus very desirable to have appropriate 27 measurement tools in place in advance. We discuss some appropriate 28 tools from the network and application perspective. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 9, 2011. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Connectivity Issues . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Unmanaged Tunnels . . . . . . . . . . . . . . . . . . . . 4 66 2.2. Tunnel Broker first-hop delays . . . . . . . . . . . . . . 5 67 2.3. Connection Timeouts . . . . . . . . . . . . . . . . . . . 5 68 2.4. PMTU Discovery . . . . . . . . . . . . . . . . . . . . . . 7 69 2.5. Rogue Router Advertisements . . . . . . . . . . . . . . . 7 70 2.6. Tunnel performance . . . . . . . . . . . . . . . . . . . . 8 71 2.7. AAAA record advertised but service not enabled . . . . . . 8 72 2.8. IPv6 Reverse DNS . . . . . . . . . . . . . . . . . . . . . 9 73 3. Instrumentation . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1. IPv6 traffic levels . . . . . . . . . . . . . . . . . . . 9 75 3.2. Network flow records . . . . . . . . . . . . . . . . . . . 10 76 3.3. Client Web Access Success Rate . . . . . . . . . . . . . . 10 77 3.4. Tools to measure IPv6 brokenness . . . . . . . . . . . . . 10 78 3.5. IPv4 Performance Comparison . . . . . . . . . . . . . . . 11 79 3.6. User Tickets . . . . . . . . . . . . . . . . . . . . . . . 11 80 3.7. Security monitoring . . . . . . . . . . . . . . . . . . . 11 81 4. IPv6-only testing . . . . . . . . . . . . . . . . . . . . . . 11 82 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 86 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 Despite the recent exhaustion of the available IPv4 address pool, 92 deployment of IPv6 remains limited. To help encourage organisations 93 to trial production deployment, ISOC has declared June 8th 2011 as 94 World IPv6 Day [ISOC]. Organisations are encouraged to use this day 95 to test IPv6 in production by making their main, externally-facing 96 websites available over IPv6. Sites planning to turn on IPv6 for 97 access in their network in the interest of World IPv6 Day should 98 ensure this is completed well before the day, and commit to leaving 99 it active after the event, and thus using the method they would 100 choose to do so indefinitely. At the current time, this would 101 generally mean enabling dual-stack networking with IPv4 running 102 alongside IPv6. However, IPv6-only networks are ultimately 103 inevitable, and so some sites may choose to use June 8th to undertake 104 some focused tests on that deployment model. 106 The purpose of this document is two-fold. One is to discuss common 107 IPv6 connectivity issues that are likely to arise on June 8th, with a 108 focus on dual-stack networking (which is likely to be how the vast 109 majority of sites take part). Most of the issues discussed in this 110 text are those that would affect an end site or enterprise network 111 running IPv6, but may be applicable elsewhere. Highlighting the 112 issues should help raise awareness of those problems and possible 113 mitigations. The other purpose is to encourage organisations to 114 think about how they might get useful instrumentation in place to 115 observe what happens in and to/from their networks on the day, both 116 from the network and application perspective. Such measurement tools 117 are likely to be useful in the longer term, so once deployed they 118 could be left in place beyond June 8th. 120 For sites providing content, June 8th will be a chance to make some 121 public facing services available over IPv6, most likely web content 122 using their production domain (e.g. www.example.com) rather than a 123 contrived IPv6 test domain (e.g. www.ipv6.example.com). Enabling 124 public-facing Internet services is a reasonable first step for any 125 organisation deploying IPv6. For ISPs, supporting IPv6 for their 126 Internet-facing services (web, mail, etc.) and recording the impact 127 of World IPv6 Day on their IPv4-only customers is an appropriate 128 action. For sites enabling clients, doing so initially in their IT 129 department may be appropriate; for educational sites enabling IPv6 on 130 eduroam wireless networks could be appropriate given the underlying 131 802.1x authentication technology is IP version independent. 133 It should be emphasised that while World IPv6 Day is in many senses 134 an 'experiment' or 'test flight' for IPv6, organisations should 135 strongly consider deploying IPv6 in exactly the same robust way that 136 they would do if they were deploying IPv6 and leaving it enabled 137 indefinitely. Similarly, applying measures to improve IPv6 138 robustness, e.g. improved ICMPv6 filtering practice, should be 139 considered long term benefits. That they 'affect' the experiment is 140 not a problem; indeed all measures that improve the robustness of 141 IPv6 deployment should be seen as worthwhile. There will still be 142 problems found, but these can at least be recognised and work done to 143 make them better. 145 The document also includes a brief section on tools that might be 146 used to test IPv6-only operation. 148 The scope of this document is purely informational to provoke 149 discussion. 151 2. Connectivity Issues 153 In this section we review some common causes of IPv6 connectivity 154 issues, oriented towards those that end sites or enterprises may have 155 some ability to influence or mitigate. Some issues, such as transit 156 arrangements, are not included - currently the focus is on end sites 157 (or users) who may take part in the World IPv6 Day. Some IPv6 158 connectivity test sites are emerging, for example [testipv6]. There 159 is no significance to the order in which issues are listed. 161 2.1. Unmanaged Tunnels 163 One cause of connectivity problems is the use of unmanaged tunnels, 164 in particular 'automated' methods that are not provisioned by the 165 user's ISP. The most common example is 6to4 [RFC3056], or more 166 specifically the 6to4 relay approach described in [RFC3068]. A 167 native IPv6 host communicating with a 6to4 host will require both 168 hosts to have access to an appropriately capable 6to4 relay (which 169 may or may not be the same relay). If a host in a native IPv6 170 network has no route to 2002::/16 it cannot send traffic to a 6to4 171 host. Similarly, a 6to4 router that cannot reach the well-known IPv4 172 anycast relay address cannot send traffic to a native IPv6 network. 173 There are also potential issues with Protocol 41 filtering at site 174 borders close to the client. 176 A presentation by Geoff Huston at IETF80 [Huston2011] highlighted the 177 connection failure rates with 6to4, measured in excess of 15%, as 178 well as the additional latency in 6to4 communications, with 6to4 179 showing an average additional 1.2s latency per retrieval. 181 One approach to this problem is to encourage sites/ISPs to run local 182 relays, as discussed in [I-D.carpenter-v6ops-6to4-teredo-advisory]. 183 This draft discusses how to make 6to4 more robust in situations where 184 there is a conscious decision to use it. Sites using 6to4 should 185 consider deploying local relays to increase the chance of a good IPv6 186 experience. The alternative to reduce such problems is simply to 187 move 6to4 to Historic, as proposed in 188 [I-D.troan-v6ops-6to4-to-historic]. This would mean 6to4 would not 189 be enabled by default anywhere, and once its usage had reduced 190 enough, relays could be turned off. 192 There may still be some CPE routers that do enable 6to4 by default; 193 it is likely that devices behind such routers will experience 194 problems on World IPv6 Day. 196 Connection failures and latency with the Teredo protocol [RFC4380] 197 were also highlighted by Geoff Huston's IETF80 presentation. Teredo 198 connection failure rates were as high as 35%, with 1-3s additional 199 latency. One of the connection issues is reliance on the ICMPv6 200 probe packet being able to reach the destination host; in practice 201 filters may block these. Thus Teredo should not be considered a 202 reliable means of accessing the IPv6 Internet. 204 2.2. Tunnel Broker first-hop delays 206 IPv6 tunnel brokers, such as those provided by SixXS 207 (http://www.sixxs.net) and Hurricane Electric 208 (http://tunnelbroker.net) provide a more robust, managed approach to 209 IPv6-in-IPv4 tunnelled access than 6to4. Individual users interested 210 in IPv6 access for World IPv6 Day, in the absence of IPv6 support 211 from their ISP, should consider registering to use a free tunnel 212 broker. It would be sensible to register for and test your broker 213 client well in advance of IPv6 Day, and ideally plan to keep it 214 available beyond that date, until your ISP provides IPv6 natively for 215 you. One set of test sites to use would be the list cited on the 216 ISOC World IPv6 Day site [ISOCsites]. 218 When choosing a broker service, it is prudent to pick one with a 219 presence near to you that has a minimal round trip time. Providers 220 such as SixXS and HE have tunnel broker servers in many countries. 221 Beware picking a broker in another continent that may add 150ms+ to 222 your round trip times. 224 2.3. Connection Timeouts 226 One of the main drivers for IPv6 Day is identifying and fixing the 227 problems that can lead to connection timeouts. Because unreliable 228 IPv6 connectivity leads to intensely frustrating problems for end- 229 users, it is essential that people motivated to deploy IPv6 230 connectivity, whether for themselves, or for a larger network, only 231 do so in a well-supported, production-quality fashion. 233 Where dual-stack systems - or rather the applications running on them 234 - have a choice of IPv4 or IPv6 connectivity, timeouts can occur if 235 there is no connectivity on the preferred protocol. For example, if 236 both A and AAAA DNS records exists for a web server, and IPv6 237 connectivity is broken, there is likely to be some timeout for the 238 browser before the connection drops back to IPv4. 240 A bigger problem exists if the application or OS tries IPv6 first and 241 then does not fall back to IPv4. A bug in versions of Opera prior to 242 10.5 caused such behaviour, which was obviously a big issue for Opera 243 users trying to access dual-stack web sites with broken IPv6 244 connectivity. 246 The author has undertaken some informal tests at his own site, which 247 shows how different combinations of browsers and operating systems 248 behave in the event of IPv6 connections failing or when ICMP 249 unreachables are received. On Linux/Firefox, web connections timeout 250 after 20 seconds for 'no response', but immediately for unreachables. 251 In contrast, Windows Vista/IE was 20 seconds regardless of 252 unreachables being received. Any non-trivial delay will cause 253 significant user frustration. 255 A more complete set of tests was run by Teemu Savolainen and reported 256 at IETF80 [Savolainen2011]. Although the tests were only samples, 257 they confirmed the results, also showing experiences across a much 258 broader range of platforms, and that the problems with Vista/IE are 259 repeated with Win 7/IE. It's thus clear that if major content 260 providers enable IPv6 on World IPv6 Day, and end users for some 261 reason try to access the content with broken IPv6 connectivity, they 262 are likely to experience significant timeout issues. 264 This problem is probably the main reason that Google implemented a 265 AAAA whitelisting system for its test sites. The sites had to 266 demonstrate they had good IPv6 connectivity before being allowed into 267 the test programme. The topic is discussed in 268 [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]. For the sake of 269 World IPv6 Day, it is expected that no such whitelisting is in place 270 - that is, after all, the point of having a day dedicated to testing 271 IPv6 in production. 273 An interesting suggestion to handle the problem is the 'happy 274 eyeballs' approach described in [I-D.ietf-v6ops-happy-eyeballs]. 275 This approach is now also being suggested for multiple interface 276 systems, as per [I-D.chen-mif-happy-eyeballs-extension]. The happy 277 eyeballs philosophy is to try both IPv4 and IPv6 together, and keep 278 the first working connection up, remembering the result for future 279 connection attempts. It may prefer IPv6 slightly in initial 280 connections rather than trying connections exactly simultaneously. 282 It is an interesting approach, though some people are concerned about 283 the additional connection load, or that this 'workaround' is simply 284 masking underlying problems that should be fixed. 286 2.4. PMTU Discovery 288 IPv6 mandates that fragmentation is only undertaken by the sending 289 node, and thus IPv6 requires working PMTU Discovery [RFC1981]. An 290 existing RFC gives Recommendations for Filtering ICMPv6 Messages in 291 Firewalls [RFC4890]; if this guidance is not followed, connectivity 292 problems are likely to arise. Blindly filtering all ICMPv6 messages 293 is not good practise. Filtering ICMP is a common practice in some 294 IPv4 networks today. Adopting the same approach to ICMPv6 when 295 deploying IPv6 networks will cause connectivity issues for users of 296 the network filtering ICMPv6 and hosts trying to reach the filtered 297 network. RFC 4890 is therefore an important document for IPv6 298 deployment engineers to read and it is similarly important to verify 299 that IPv6 firewall deployments support appropriate configurations for 300 ICMPv6 filtering. 302 The minimum MTU for IPv6 is 1280 bytes. Checking the MTU is an 303 important step when connectivity issues arise. Where PMTUD is not 304 working or not implemented, the using the minimum MTU is likely to 305 resolve the problem, though not give optimal performance (the cause 306 should still be investigated and resolved for longer term benefit). 307 Tunnel broker services such as SixXS and HE set their MTUs to default 308 to 1280, probably due to the varying conditions their customers may 309 be in. However, it is preferable for enterprise networks to 310 configure appropriate ICMPv6 filtering to allow PMTUD to operate and 311 establish the most efficient MTUs for a link. 313 2.5. Rogue Router Advertisements 315 Within a site, hosts may use IPv6 Stateless Address Autoconfiguration 316 (SLAAC) [RFC4862]. However, it is possible for accidental (or 317 malicious) rogue RAs to cause connectivity issues, as described in 318 the Rogue Router Advertisement Problem Statement [RFC6104]. 320 A typical cause of rogue RAs is Windows ICS, which can present a 321 rogue 6to4 router on its wireless interface. This will cause hosts 322 to potentially autoconfigure two global IPv6 addresses and pick the 323 wrong default router, with unpredictable results. As a (bad) example 324 the author experienced a scenario where he had a rogue 6to4 RA, but 325 because the rogue 6to4 was working he was able to access IPv6 326 networks outside his own network, but could not access most internal 327 hosts inside his own network because he was unwittingly using 6to4 328 from outside into his own network, and thus being firewalled from 329 those internal hosts. 331 In many cases, default address selection [RFC3484] (and 332 [I-D.ietf-6man-rfc3484-revise]) would avoid such cases, because the 333 address selection rules should prefer, or can be configured to 334 prefer, native IPv6 over 6to4. However not all operating systems 335 implement RFC 3484 yet, in particular MacOS X (though support may be 336 appearing in Lion). Where rogue RAs cause broken IPv6 behaviour, the 337 timeout issues discussed above may apply. 339 Adding ACLs to your switches to block ICMPv6 Type 134 packets on 340 ports that do not have routers connected would also minimise the 341 impact of rogue RAs. A more elegant solution is RA Guard [RFC6105], 342 and another is use of SEcure Neighbour Discovery (SEND) [RFC3971]. 343 However neither is widely implemented yet. Indeed, any reported 344 operational experience of SEND in an enterprise network would be very 345 welcome. 347 Finally, there is a tool called RAmond, available freely from 348 http://ramond.sourceforge.net, that can be configured to detect and 349 issue deprecating RAs against observed rogue RAs. This software is 350 based on rafixd. 352 2.6. Tunnel performance 354 In scenarios where sites currently have manually configured tunnels 355 to gain IPv6 connectivity, it may be the case that such encapsulation 356 is performed by a router's CPU, in which case unexpected high volumes 357 of traffic may cause problems. Bear in mind that on World IPv6 Day, 358 you may start using IPv6 by default for some high bandwidth 359 applications that you had not used before, e.g. YouTube from Google. 360 It may be prudent to estimate your load for such applications in 361 advance, and test the capability of your tunnelling solution to 362 handle that load. 364 2.7. AAAA record advertised but service not enabled 366 If enabling a service for World IPv6 Day, be aware of other existing 367 services that may be running on the same system. If a server has 368 multiple functions, all services should be IPv6 enabled before a AAAA 369 record is entered into the DNS for services that may use that name. 371 A related consideration is to make sure that firewalls don't just 372 drop IPv6 packets to ports that are not in use. It's better if the 373 firewall or host sends an unreachable indication or a TCP RST to 374 avoid a potential timeout. For example, if you add a AAAA record for 375 your web server that also runs say FTP, where FTP is IPv4 only, 376 either the firewall should have port 21 open or the firewall should 377 be configured ta send a TCP RST. There are of course tradeoffs in 378 enabling ICMP unreachables. 380 2.8. IPv6 Reverse DNS 382 Presence of IPv6 reverse DNS records is used by many systems as a 383 security method. For example, many mail exchangers will only accept 384 SMTP connections from IP addresses with a reverse DNS entry. It is 385 thus important for such records to exist where, for example, a site 386 is sending mail out over IPv6 transport. It is not necessarily the 387 case that such connections will fall back to IPv4 if reverse records 388 are not present. 390 3. Instrumentation 392 In this section we discuss potential instrumentation approaches that 393 may be configured in advance of World IPv6 Day, and then retained 394 longer term after the event. These are particularly useful if your 395 site is turning on AAAA records for its production web presence (for 396 example) and wants to get the best insight into how the systems 397 performed and the nature of the end user experience. 399 These measurements should complement informal, subjective reports 400 from users at participating sites. It is probably prudent to make at 401 least your organisation's IT staff aware of the 'at risk' day, and 402 actions they should take should they experience problems. It may 403 also be desirable to undertake some form of user survey soon 404 afterwards; whether you inform general users in advance is an issue 405 for each site. The ARIN IPv6 wiki is a good source of such advice 406 [ARINwiki]. 408 3.1. IPv6 traffic levels 410 It should be possible to measure raw IPv6 traffic levels 411 independently on dual-stack switch/router platforms, given 412 implementations of appropriate MIBs. Sites should take steps to 413 ensure they have the tools in place to be able to view the relative 414 levels of IPv4 and IPv6 traffic over time. 416 Application level measurement is also desirable, because handling of 417 choice (preference) of protocol used lies with the application if 418 both A and AAAA records are returned. Sites should be aware that due 419 to IPv6 Privacy Extensions [RFC4941] application logs may show more 420 apparent different clients connecting, due to clients cycling the 421 source IPv6 address they use over time. 423 The types of information gathered might for example include: 425 o IPv6 traffic volume, sources of IPv6 traffic by AS, types of IPv6 426 traffic (e.g. native, 6to4, Teredo, tunnelled); 428 o IPv6 application mix, comparison with IPv4; 430 o The number and type of IPv6 client connections. 432 3.2. Network flow records 434 Where available, sites should seek to generate and record network 435 flow records for traffic, to maximise opportunities to analyse 436 traffic patterns after the event, or in the case of reports of 437 specific problems. Netflow v9 supports IPv6. Open source IPv6- 438 capable Netflow collectors also exist, e.g. nfsen, from 439 http://nfsen.sourceforge.net. 441 3.3. Client Web Access Success Rate 443 There have been some recent studies on the capabilities of web 444 clients to access content on dual-stack servers by IPv4 or IPv6 in 445 the presence of both A and AAAA records existing for a web domain. 447 One good example is that of [Anderson10], as reported at RIPE-61, 448 where the author set up some application (web server) oriented tests 449 for his newspaper content in Norway. The methodology was to add an 450 invisible IFRAME to his site that would include IMG links randomly to 451 1x1 images that were served either via an IPv4-only target or a dual- 452 stack target. Variation in the hit rates would imply IPv6 453 brokenness. By analysing the http metadata information could be 454 gleaned on the cause of the brokenness. Results in Q4'2009 showed 455 0.2-0.3% brokenness, including the Opera bug mentioned above. 457 Recent figures published by Google suggest at most a 0.1% level of 458 brokenness, indicating some improvement, but that level is still 459 potentially 1 in 1000 users with a problem. 461 3.4. Tools to measure IPv6 brokenness 463 Sites may wish to make their own measurements of IPv6 brokenness 464 rather than relying on third party reports. There are some openly 465 available tools available that work along similar principles to the 466 method proposed by Tore Anderson above. 468 The APNIC Labs test tool uses a combination of JavaScript and Google 469 Analytics to measure various types of brokenness [APNIC]. Eric 470 Vyncke's tool [Vyncke] measures a slightly smaller set of types of 471 brokenness, but also looks very useful, with additional reports on 472 the browser type for each failure. The author is currently using the 473 latter tool, and plans to enable the APNIC measurement system shortly 474 when other Analytics updates are applied locally. 476 3.5. IPv4 Performance Comparison 478 Where a dual-stack service is deployed, measuring the relative 479 performance of both protocols is desirable. This may primarily be a 480 measurement of throughput or delay, but may also include 481 availability/uptime measurement. A site may choose to set up its own 482 performance measuring framework, for example using open source 483 bandwidth and throughput test tools. Participants in World IPv6 Day 484 will be monitored from a broad range of locations and measurements 485 will be available to show availability of AAAA records, reachability 486 to http service, latency and availability over time. 488 3.6. User Tickets 490 It is possible a higher than usual user ticket rate for connectivity 491 issues may be experienced. being able to categorise these cases for 492 subsequent analysis is desirable. 494 3.7. Security monitoring 496 We mentioned RAmond above in the context of watching for rogue RAs. 497 There is another useful package called NDPmon, also available freely 498 from http://ndpmon.sourceforge.net, that can be configured to watch 499 for certain types of IPv6 'abuse' on your local network. It may be 500 interesting to run the tool to confirm whether any 'bad' traffic is 501 observed within your network on World IPv6 Day. 503 4. IPv6-only testing 505 The long-term IPv6 deployment plan is IPv6-only networking, rather 506 than dual-stack. It is not clear how quickly significant IPv6-only 507 networks will emerge, but testing of approaches to IPv6-only 508 operation is desirable as soon as possible. A draft by Jari Arkko 509 and Ari Keranen describes some such experiences 510 [I-D.arkko-ipv6-only-experience]. 512 Some experience of NAT64 [RFC6146] has been described in 513 [I-D.tan-v6ops-nat64-experiences], though this appears to have used 514 only NAT-PT so far. An implementation of NAT64 is available at 515 http://ecdysis.viagenie.ca. Operational experience of IVI is also 516 desirable. An implementation of IVI is available at 517 http://www.ivi2.org/IVI. 519 5. Conclusions 521 With the ISOC World IPv6 Day event due on June 8th 2011, this 522 document aims to help focus attention on both improving awareness and 523 mitigations of common causes of IPv6 connectivity problems, and 524 encouraging sites and organisations to introduce appropriate 525 instrumentation into their networks so they can observe traffic 526 behaviour appropriately. 528 This is still an early version of the text, and is thus a little 529 drafty. All comments are very welcome towards a mature version in 530 advance of June. 532 6. Security Considerations 534 There are no extra security consideration for this document. 536 7. IANA Considerations 538 There are no extra IANA consideration for this document. 540 8. Acknowledgments 542 To be added. 544 9. Informative References 546 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 547 for IP version 6", RFC 1981, August 1996. 549 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 550 via IPv4 Clouds", RFC 3056, February 2001. 552 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 553 RFC 3068, June 2001. 555 [RFC3484] Draves, R., "Default Address Selection for Internet 556 Protocol version 6 (IPv6)", RFC 3484, February 2003. 558 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 559 Neighbor Discovery (SEND)", RFC 3971, March 2005. 561 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 562 Network Address Translations (NATs)", RFC 4380, 563 February 2006. 565 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 566 Address Autoconfiguration", RFC 4862, September 2007. 568 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 569 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 571 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 572 Extensions for Stateless Address Autoconfiguration in 573 IPv6", RFC 4941, September 2007. 575 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 576 Problem Statement", RFC 6104, February 2011. 578 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 579 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 580 February 2011. 582 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 583 NAT64: Network Address and Protocol Translation from IPv6 584 Clients to IPv4 Servers", RFC 6146, April 2011. 586 [I-D.carpenter-v6ops-6to4-teredo-advisory] 587 Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 588 draft-carpenter-v6ops-6to4-teredo-advisory-03 (work in 589 progress), March 2011. 591 [I-D.ietf-v6ops-happy-eyeballs] 592 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending 593 Towards Success with Dual-Stack Hosts", 594 draft-ietf-v6ops-happy-eyeballs-02 (work in progress), 595 May 2011. 597 [I-D.tan-v6ops-nat64-experiences] 598 Tan, J., Lin, J., and W. Li, "Experience from NAT64 599 applications", draft-tan-v6ops-nat64-experiences-00 (work 600 in progress), March 2011. 602 [I-D.troan-v6ops-6to4-to-historic] 603 Troan, O., "Request to move Connection of IPv6 Domains via 604 IPv4 Clouds (6to4) to Historic status", 605 draft-troan-v6ops-6to4-to-historic-01 (work in progress), 606 March 2011. 608 [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications] 609 Livingood, J., "IPv6 AAAA DNS Whitelisting Implications", 610 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05 611 (work in progress), May 2011. 613 [I-D.chen-mif-happy-eyeballs-extension] 614 Chen, G. and C. Williams, "Happy Eyeballs Extension for 615 Multiple Interfaces", 616 draft-chen-mif-happy-eyeballs-extension-01 (work in 617 progress), March 2011. 619 [I-D.ietf-6man-rfc3484-revise] 620 Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC 621 3484 Default Address Selection for IPv6", 622 draft-ietf-6man-rfc3484-revise-02 (work in progress), 623 March 2011. 625 [I-D.arkko-ipv6-only-experience] 626 Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 627 Network", draft-arkko-ipv6-only-experience-03 (work in 628 progress), April 2011. 630 [APNIC] "IPv6 Capability Tracker", . 632 [Vyncke] Vyncke, E., "Estimation of IPv6 brokenness", 633 . 635 [ARINwiki] 636 "ARIN IPv6 Wiki", . 639 [testipv6] 640 "Test IPv6", . 642 [ISOC] "World IPv6 Day", . 644 [Huston2011] 645 Huston, G., "Stacking it Up: Experimental Observations on 646 the operation of Dual Stack Services", 2011, 647 . 649 [Savolainen2011] 650 Savolainen, T., "Experiences of host behaviour in broken 651 IPv6 networks", 2011, 652 . 654 [ISOCsites] 655 "IPv6 Enabled Websites", 656 . 658 [Anderson10] 659 Anderson, T., "Measuring and Combating IPv6 Brokenness", 660 2010, 661 . 663 Authors' Addresses 665 Tim Chown 666 University of Southampton 667 Highfield 668 Southampton, Hampshire SO17 1BJ 669 United Kingdom 671 Email: tjc@ecs.soton.ac.uk 673 Mat Ford 674 Internet Society 675 Geneva, 676 Switzerland 678 Email: ford@isoc.org 680 Stig Venaas 681 Cisco Systems 682 Tasman Drive 683 San Jose, CA 95134 684 USA 686 Email: stig@cisco.com